[Greasemonkey] ISWEST - Idiot-Simple WEb STorage

[Anton Berezin]

On Thu, Jun 22, 2006 at 08:56:01AM -0500, Jeremy Dunck wrote:
> On 6/22/06, Anton Berezin <tobez at tobez.org> wrote:
> >  http://iswest.tobez.org/docs/api.txt
> >
> 
> >From there:
> "
> Any request can lead to the "error" being set to true with corresponding
> error description in "error_str".  If a request succeeds, it might or
> might not set "error" to a false value, that is, "error" may be
> undefined in a result of a successful request.
> "
> 
> Huh?  If error can be set at any time, even on success, what good is
> it?  How do I tell if there was an actual error?

I probably did not express myself clear enough.  On success, error is either
undefined or set to a false value, so that the check

   if (result.error) { ... }

is sufficient.  In practice, in the current implementation error is
undefined on success.

> "
> It does not matter whether the request is a POST or a
> GET.
> "
> The HTTP spec and Google Web Accelerator disagree with that.

Well, there is that.  I don't want to completely exclude GET from the
consideration, since it makes creating a script element pointing to the
server with the right parameters possible.  I guess if I provide suitable
cache control headers, that will do?

Or were you talking about the "GET with the same parameters should produce
the same results" distinction?

> >var iswest = new Iswest("http://iswest.tobez.org/iswest.cgi/", 
> >"this-is-rw-id");

> Does each ID get its own namespace, and if so, what use is a read-only
> ID?  Oh, I see, it's sort of implicit that there's one rw and one r
> key per account?

Yes, if you want to publish RO ID to a group of people without giving them
update rights.  In theory any number of RW and RO keys could refer to the
account/namespace - the implementation does not forbid that, so I did not
forbid that in the API as well.  In practice, one RW and one RO are used.

> >iswest.put(
> ...
> 
> Nice, though it would have been a bit clearer to do the put and the
> get calls separately to illustrate.  The nested get call looks a bit
> odd.  :)

Yes, I'll update the example on the webpage, thanks.

> >Quite obviously, other methods could be used, such as creating a script
> >element pointing to an ISWEST server, using JSONP variety of the API.
> 
> I didn't know the JSON-result-with-callback had a name, so thanks for that.
> 
> 
> >The modified version of the script could be found at
> >http://iswest.tobez.org/examples/google-calender-todo.user.js .
> 
> Nice.  So the only concern I have over this whole proposal is whether
> I can count on the data store in terms of longevity, reliability,
> security...

Well.  As I said, no warranties.  On the other hand, I do intend to keep
this server running for as long as possible, and I do make backups, and
although the current hardware is puny (that might change in the future), it
has a decent network pipe.  So, provided I don't get hit by a bus...

> I guess you're thinking that people could host their own ISWEST store, or
> that the selection of a store for a particular script or application would
> be done on a case-by-case basis.

That is an option, that's one of the reasons I published the complete
sources.  That said, I intend to run the service in question for the
foreseeable future.

> Which is fine.  But I wouldn't store anything important without some
> promises that it'd be there tomorrow. :)  The security piece could
> just be encrypting the data before sending, I suppose, but then you
> have the issue of sharing keys.

There is that.  But it is easier to share keys than the complete
dataset.

Thanks for the feedback, much appreciated.

Cheers,
\Anton.
-- 
An undefined problem has an infinite number of solutions.
-- Robert A. Humphrey