Re: Uses cases for the Media Gallery API

Rich, Francois,

I'm coming in a bit late on this conversation, but I want to get it 
moving again.

I have tested several Applications (non-web) in relationship to a large 
media archive, of 70k mp3 files.
I wasn't able to use any of them in a portable manner. Though they fit 
fine on a portable
usb drive, none of the apps were built to handle a portable list of 
files; m3u (and other playlist formats) just isn't up for the task.

I've been working full time this past year developing an RIA, an HTML5 
application,
and part of that task has been supporting over a dozen "cloud" 
providers, as well
as supporting local storage via any/all means available. That includes 
File API, Web SQL [deprecated],
localStorage and IndexedDB. It also includes managing generated 
thumbnails for the collections,
as opening up even a hundred images for browsing gets a little slow in 
the UA.

So, that's my background, and at the same time, that's me providing some 
grounded use cases.

Now, into the thread...

On 12/08/2010 05:16 PM, Rich Tibbett wrote:
> >Hi Francois,
> >
> >Thanks for taking the time to provide these use cases.
> >
> > I see all of these use cases being satisfied with a few additions to the
> > FileSystem API, rather than creating a Gallery API. Because Gallery
> > Objects are simply certain types of files it would be better if this
> > could build on top of the FileSystem API.

I'm a fan of the File API, and I did indeed base one layer (the local 
storage)
of an application on a class I wrote first for the FileSystem API.

That said, file systems are really terrible for this kind of work.
IndexedDB provides a largely superior solution, as it acts more as a 
data store
than it does a file system. RPC / Cloud storage services also act more 
as data stores,
with file system semantics "available", by simply prefix searches.

You can simply look to Amazon or Google to see that data stores make sense.

The current goals of the File System API don't really jive with 
arbitrary / media metadata.
That's my take on it anyway.

At present, it seems that Google / Chromium is the group directing the 
file system API.
They're still working through the basics.

I think it makes more sense to keep Gallery API as a separate spec. I'm 
fine with borrowings
and references.


> > I'd actually prefer that we focus these use cases around the FileSystem
> > API. It would be good if within the FileSystem API I were able to mount
> > specific folders within my filesystem and then grant access to those
> > folders at runtime. Currently the FileSystem API is based on the ability
> > to provide access to a sand-boxed temporary/permanent file system
> > environment instead of being able to mount or symlink existing folders
> > and file systems.

I'm looking forward to this use case as well (mounted folders). 
Currently, webkitDirectory doesn't cut it,
and Google is looking to switch from simply creating a directory 
structure using native OS semantics,
to using a virtual file system, in one method or another.

In doing so, it will be necessary that they allow mounting of user 
directories, otherwise, the ability
to use OS semantics is completely lost. That is, there would be no 
guaranteed way to place a file in a directory,
on the user's computer, so the user can copy that directory from a file 
manager.

>  I think the main point is to give access to an indexed database that 
is maintained under the hood, and avoid the need for any application to 
do that on its own.

Both Mozilla and WebKit built their current generation of IndexedDB on 
top of SQLite.
There's certainly precedence for this.

In our application, we still have to do a lot of mapping, but it would 
have helped to skip
a step or two.


> >It also helps to take a more generic approach and build such use cases
> >on file systems in general.

>  I'm fine if you want to map these use cases to file systems. After 
all, an index on artist and albums is a tree, and a tree can easily be 
mapped to a file system through symlinks. In short, you could "mount" 
different views as folders/files, but there would still need to be a 
need for some naming convention for the application to know what the 
view represents (to search for specific albums, for instance). The final 
solution is really up to to you, guys ;)

Symlinks are not part of the current filesystem spec; I doubt they will be.
I would like to see views looked at a little more, in the current spec.

The current gallery spec has this:
"length -- the number of media objects in the gallery."

We don't actually know how many media objects are in a gallery. Only how 
many are reported for a particular find() query.
Some providers give numbers, some don't.

For many providers, the full directory structure is only known as we 
crawl through it.
Sending a spider through the entire structure is strongly discouraged by 
some services.

Here's the structure we're using, more or less:
StorageManager->ResourceManager->PathManager->LocationManager->GalleryManager

StorageManager just implements the same set of methods over the local 
storage types I mentioned.
Mainly: "find filenameMask*", exists "filename", remove "filename", 
write "filename".

Resource Manager abstracts some of that, semantics like 
"saveImageReferenceToFile(filename)".
PathManage and LocationManager stash the image and metadata, so that we 
only save one copy
of an image, based on its sha1 hash, and don't do unnecessary saves / 
restores.

And finally, at the end there, we've got the abstracted gallery, where 
we can do simple find() commands,
and pull data from that pipe line, getting our file from the disk, and 
our metadata from where-ever it may be.
And it may also be on the disk (when recovering/importing), in a 
serialized json file.


Bit lengthy, but I wanted to get this message out there. There are 
definitely uses for higher levels of
abstraction in managed data. It took us a lot of work to learn and build 
that pipeline; it would have
been easier we knew the scope of it ahead of time... that's something 
that specs often provide, even
if the UA does not implement it.



-Charles