Re: [whatwg] Shared storage

A smarter file-picker is not going to address the significant UX and
performance issues with save->open for moving files between
applications.

Many common workflows involve having files open in multiple editors at
once, saving in one app, reloading in others. Some applications have
built in affordances for this, like text editors and IDEs that
automatically reload when the content has changed on disk. One
real-world example: Unity's project management lets you pull various
resources into your game, then live-edit the resources in Maya,
Photoshop, etc with the IDE automatically pulling in the changes and
running builds to update the content.

If this kind of interchange and interaction requires literally doing
save->confirm save->open->pick saved file from wherever it went *every
time* nobody will use these applications. The applications that get
used will be ones that figure out a clever set of workarounds like the
postmessage/blessed domain one mentioned in the original post. That
sort of approach is something that will easily lead to a walled garden
library that 'solves the problem' and becomes widely adopted, when
HTML5 itself could probably tackle the issue without a bunch of new
scaffolding or significant new APIs.

Mind you, I'm not saying this is an easy problem to solve - just that
it's worth solving and that save->open is not a solution.

One idea: 'transferable' support for indexedDB such that a blessed
domain can postMessage an indexedDB database over to another domain,
to allow shared access to storage for a specific database. This
doesn't address all the problems in the original post, but simplifies
the task of sharing content between applications. This would probably
also pay dividends for web workers.
(Actually, is this already specced? I only know that worker access to
indexedDB wasn't available in Gecko or Blink the last time I checked
and didn't seem to be a planned addition.)

Another option: Some simple protocol for creating 'shared' databases
using a special token in the name you pass to indexedDB.open? I can
see how this might be a compat problem, but it would be a pretty
low-overhead way to expose basic support for this. Perhaps the unique
token you pass would be created by a feature-detectable API, sort of
like how createObjectURL works. That would give you a single point
where you can insert approval/feedback UI and do any necessary I/O to
set up sharing, while the rest of the database flow remains unchanged.

Synchronization between two processes mutually touching the DB is hard
but you could just punt on that like is currently done with typed
arrays - neutering or equivalent. Alternately, a single database-wide
lock would probably cover things - that's the approach SQLite used for
a long time.

-kg


On 28 October 2014 12:17, Nils Dagsson Moskopp
<nils@dieweltistgarnichtso.net> wrote:
> Tobie Langel <tobie.langel@gmail.com> writes:
>
>> On Tue, Oct 28, 2014 at 6:33 PM, Ian Hickson <ian@hixie.ch> wrote:
>>
>>> On Sat, 15 Feb 2014, Brett Zamir wrote:
>>> >
>>> > The desktop PC thankfully evolved into allowing third-party software
>>> > which could create and edit files shareable by other third-party
>>> > software which would have the same rights to do the same. The importance
>>> > of this can hardly be overestimated.
>>> >
>>> > Yet today, on the web, there appears to be no standard way to create
>>> > content in such an agnostic manner whereby users have full, built-in,
>>> > locally-controlled portability of their data.
>>>
>>> Why can't you just do the same as used to be done? Download the resource
>>> locally ("save", using <a href download>), then upload it to the new site
>>> ("open", using <input type=file>)?
>>>
>>
>> Because that's a terrible user experience?
>
> If that is indeed the case, the terrible user experience is likely a
> feature of your user agent. Many mobile UAs currently offer several
> alternatives to the standard file-picker, no change in HTML needed.
>
> --
> Nils Dagsson Moskopp // erlehmann
> <http://dieweltistgarnichtso.net>

Received on Tuesday, 28 October 2014 19:40:34 UTC