Datastore / Persistance

[kixx]

One of the most exciting things happening on the web these days is the
"comeback" of a rich client in the form of browser extensions in
addition to the Adobe Air and Microsoft Silverlight platforms.
Mozilla is in a unique position to create a new dimension for the
Internet other than the WWW. The Mozilla code base is uniquely cross
platform, with extremely broad functionality. The problem with
adoption, up to this point, has been a mix of complexity and lack of
documentation for developers.

I share Aza's dream:
http://www.azarask.in/blog/post/my-dream-way-to-write-a-firefox-extension/

Jetpack is changing all of that. This has the potential to put rich
client application development into the hands of almost anyone unlike
anything since Sir Tim started linking HTML documents together and
called it the World Wide Web.

So, are there any plans in the pot yet for a storage/datastore/
persistence API? If so, is the HTML5 spec going to be woven into it,
or should it be?

Aza has mentioned that he really likes the Appjet storage API. I
agree, but I'd like to add the Google App Engine Datastore API into
the discussion too.

http://appjet.com/docs/librefbrowser?page=storage
http://code.google.com/appengine/docs/python/datastore/overview.html

Is there a roadmap or ongoing discussion for this? Storage is
something I really need for the extensions I'd like to port to
Jetpack, and something that I'd like to work on.

-Kris Walker

[Andrew Wooldridge]

Another great storage option: http://www.nextdb.net/
It's like having a hosted mysql server via ajax.
-Andrew

On May 21, 4:58 am, kixx <kristoffw...@gmail.com> wrote:
> One of the most exciting things happening on the web these days is the
> "comeback" of a rich client in the form of browser extensions in
> addition to the Adobe Air and Microsoft Silverlight platforms.
> Mozilla is in a unique position to create a new dimension for the
> Internet other than the WWW.  The Mozilla code base is uniquely cross
> platform, with extremely broad functionality.  The problem with
> adoption, up to this point, has been a mix of complexity and lack of
> documentation for developers.
>

> I share Aza's dream:http://www.azarask.in/blog/post/my-dream-way-to-write-a-firefox-exten...

>
> Jetpack is changing all of that.  This has the potential to put rich
> client application development into the hands of almost anyone unlike
> anything since Sir Tim started linking HTML documents together and
> called it the World Wide Web.
>
> So, are there any plans in the pot yet for a storage/datastore/
> persistence API?  If so, is the HTML5 spec going to be woven into it,
> or should it be?
>
> Aza has mentioned that he really likes the Appjet storage API.  I
> agree, but I'd like to add the Google App Engine Datastore API into
> the discussion too.
>

> http://appjet.com/docs/librefbrowser?page=storagehttp://code.google.com/appengine/docs/python/datastore/overview.html

[rektide]

Using anything but HTML5 is insane. Jetpack ought to be able to
leverage the browsers own storage engine, without relying on a
reimplementation of another storage engine.

[Andrew Wooldridge]

Yes, but the trick is to come up with a wrapper that works across
domains and across browser versions.

Please jetpack folks please give us some kind of storage!

I'm working on a really cool game, but I cannot really do anything
beyond something basic because I cannot store the user's data beyond a
given session.
Yes, I could resort to using a server, but that's really crazy because
I know the browser has a perfectly working storage system.

-Andrew

[Aza]

Hi Andrew,

Storage is definitely something we'll be adding soon!

-- aza | ɐzɐ --

[futtta]

the latest demo on jetpack.mozillalabs.com uses the so far
undocumented function jetpack.sessionStorage:

var stash = jetpack.sessionStorage;
if( !stash.history ) stash.history = [jetpack.tabs.length]

see https://jetpack.mozillalabs.com/demos/graph/graph.js

frank

On May 25, 9:28 am, Aza <aza...@gmail.com> wrote:
> Hi Andrew,
>
> Storage is definitely something we'll be adding soon!
>
> -- aza | ɐzɐ --
>

[Andrew Wooldridge]

I'm getting an error saying jetpack.tabs.onOpen is not a function
after I install that.
Plus, is "sessionStorage" something that lives beyond the browser
quitting and restarting?

We need a persistent storage as well as one for just a given session.

Jetpack, you are so close to being something really awesome - here's
to hoping for a simple storage mechanism soon!

-Andrew

On May 26, 3:50 am, futtta <fut...@gmail.com> wrote:
> the latest demo on jetpack.mozillalabs.com uses the so far
> undocumented function jetpack.sessionStorage:
>
> var stash = jetpack.sessionStorage;
> if( !stash.history ) stash.history = [jetpack.tabs.length]
>

> seehttps://jetpack.mozillalabs.com/demos/graph/graph.js

[Aza]

Hi Andrew,

You'll have to update Jetpack to 0.1.4 (Tools -> Add-Ons -> Find Updates).

You are right, though, that sessionStorage is only temporary per storage. What would you like the permanent storage to look like?

We are thinking that something simple like jetpack.storage.hi = "beep" is an easy way to go -- just assign and go. 

-- aza | ɐzɐ --

[Andrew Wooldridge]

Yes, simple is the best way to go. What I will do on my end (for my
app) is store stuff as json encoded strings and write a little read/
write wrapper.
So, yeah that sounds great!

-Andrew

On May 26, 9:48 am, Aza <aza...@gmail.com> wrote:
> Hi Andrew,

> You'll have to update Jetpack to 0.1.4 (Tools -> Add-Ons -> Find Updates).
>
> You are right, though, that sessionStorage is only temporary per storage.
> What would you like the permanent storage to look like?
>
> We are thinking that something simple like jetpack.storage.hi = "beep" is an
> easy way to go -- just assign and go.
>
> -- aza | ɐzɐ --
>

[Iraê]

+1 for jetpack.storage.hi = "beep"

=)

-- Iraê

On May 26, 1:48 pm, Aza <aza...@gmail.com> wrote:
> Hi Andrew,

> You'll have to update Jetpack to 0.1.4 (Tools -> Add-Ons -> Find Updates).
>
> You are right, though, that sessionStorage is only temporary per storage.
> What would you like the permanent storage to look like?
>
> We are thinking that something simple like jetpack.storage.hi = "beep" is an
> easy way to go -- just assign and go.
>
> -- aza | ɐzɐ --
>

[Andrew Wooldridge]

Bump.
I really really really really want storage . Cant you tell?
Going to try to use the session storage and see how far along I can
take it. Too bad that everything the user does will be lost between
sessions, but hopefully updating the code will be easy to do once
permanent storage comes around.

-Andrew

[kixx]

Aza:

I still like the appjet way:
http://appjet.com/docs/librefbrowser?page=storage

Just create a javascript object using the StoreableObject constructor
and pass it to a storage function or constructor or something.

Could use a combination of JSON encoding and SQLite to implement the
needed object relational mapping maybe?

Is there anyone working on this? Is this something I could help write?

[cubecz]

I like the appjets approach to storage too.
But jetpack.storage.hi = "beep" sounds good or at least sufficient.
It's not robust, but it's simple enough to work with it.

[Daniel Sundstrom]

+1 for simple assignment. 

--
"Given that God is infinite, and the universe's expansion
into the great void - would you like a roasted teacake?"

"Give a man a match, and he is warm for a night. Light a man on fire, and he's warm for the rest of his life."

[rektide]

> We are thinking that something simple like jetpack.storage.hi = "beep" is an
> easy way to go -- just assign and go.

I'd vastly prefer http://dev.w3.org/html5/webstorage/#the-localstorage-attribute

It implements an actual standard http://dev.w3.org/html5/webstorage/#storage-0

interface Storage {
readonly attribute unsigned long length;
[IndexGetter] DOMString key(in unsigned long index);
[NameGetter] DOMString getItem(in DOMString key);
[NameSetter, NameCreator] void setItem(in DOMString key, in
DOMString data);
[NameDeleter] void removeItem(in DOMString key);
void clear();
};

From there, people are free to make whatever creative object wrappers
they want.

I said it before, "using anything but HTML5 is insane." As for
locality, give each Jetpack extension needs its own localstorage.
Shared data is a must. If theres a need for more partitioning, add it
in user libraries down the road, or in ext.

[rektide]

There is some additional complexity when implementing Storage events,
which I had not considered:

http://dev.w3.org/html5/webstorage/#event-storage

Even without the event interface, I think the HTML5 way is the True
Way To Go. Rather than window.localStorage, it'd be jetpack.storage,
but it would have the same interfaces.

I'll try to write up my own version of JEP-11 Persistent Storage
( https://wiki.mozilla.org/Labs/Jetpack/JEP/11 ) tonight.

> As for
> locality, give each Jetpack extension needs its own localstorage.
> Shared data is a must.  If theres a need for more partitioning, add it
> in user libraries down the road, or in ext.

[sic] as for locality, give each jetpack extention its own
localstorage.

[Andrew Wooldridge]

I consider storage not only my #1 feature rquest, but also the gate
which holds me back from developing using this in a big way.

-Andrew

On May 27, 5:45 pm, rektide <rekt...@gmail.com> wrote:
> There is some additional complexity when implementing Storage events,
> which I had not considered:
>
> http://dev.w3.org/html5/webstorage/#event-storage
>
> Even without the event interface, I think the HTML5 way is the True
> Way To Go.  Rather than window.localStorage, it'd be jetpack.storage,
> but it would have the same interfaces.
>
> I'll try to write up my own version of JEP-11 Persistent Storage

> (https://wiki.mozilla.org/Labs/Jetpack/JEP/11) tonight.

[Aza]

Can people take a look at JEP 11 and provide comments?

https://wiki.mozilla.org/Labs/Jetpack/JEP/11

-- aza | ɐzɐ --

[cubecz]

JEP 11 looks cool :)

On May 28, 5:33 am, Aza <aza...@gmail.com> wrote:
> Can people take a look at JEP 11 and provide comments?
>
> https://wiki.mozilla.org/Labs/Jetpack/JEP/11
>
> -- aza | ɐzɐ --
>

[kixx]

storage.simple lives up to it's name.

I think the async callbacks should be added to the api sooner rather
than later... maybe as an optional parameter indicating the caller's
desire to call it asynchronously?

What about searching by value rather than keys, or returning larger
datasets with a filter mechanism? Or would that make it
storage.complex?

In any case, storage.simple should be good enough to get started.