0

JSON database

How about having a dedicated JSON database together with a simplified query API locally? This might be preferable to an SQL database as it would be a lot simpler for simpler or smaller scale requirements.

In theory, a developer could request a unique database identifier, or use the URI as a namespace to ensure that no storage naming conflicts arise.

Graham

by
3 Replies
  • QUOTE (CelloSounds @ Dec 2 2008, 04:02 AM) <{POST_SNAPBACK}>
    How about having a dedicated JSON database together with a simplified query API locally? This might be preferable to an SQL database as it would be a lot simpler for simpler or smaller scale requirements.

    In theory, a developer could request a unique database identifier, or use the URI as a namespace to ensure that no storage naming conflicts arise.

    Graham


    Hi Again Graham,

    Another good idea. You and Douglas Crockford have now both suggested this. Douglas framed it much the same way you have, that maybe SQL isn't right for the web. Maybe it's too heavyweight, too clunky. Maybe a JSON style database would be more natural for the javascript programmer and cover a majority of use cases.

    HTML5 has the two extremes, Storing name/value pairs and Database storage. Is there a happy medium that we haven't considered yet? Two smart people I know think so.

    You allude to security/cross site attacks and using URI namespaces. I think these problems we can solve as there's plenty of precedent out there, and some of these mechanisms are already in HTML5.

    So "how do we get there from here?". Douglas suggested we look at persevere. I think the task would be to generate a proposed javascript interface for the database and a set of features. If it was decided that the set of interactions available in persevere was right, we could have a single javascript wrapper that works everywhere, falling back to server storage if browserplus isn't installed.

    Wanna take a crack at an API? Anyone? Blog it up and drop a link here?

    A parting shot, something I wrote in a blog post that was never published. Now we've got three mechanisms for client side storage on the table. simple key/value pairs. a JSON database. SQL databases. Which will catch on? Which will people actually use? If all three of these things were BrowserPlus services (and in some interesting future we had wide distribution, a vibrant community, and high levels of usage), we could quantitatively answer this question. A simple bar chart with the popularity of the three plugins. Then we have some empirical numbers to support our intuitions about what is "right" for the web. Popular vote, or even Natural selection, if you will :)an inspired lloyd
    0
  • Do you know CouchDB? http://incubator.apache.org/couchdb/

    QUOTE (CelloSounds @ Dec 2 2008, 04:02 AM) <{POST_SNAPBACK}>
    How about having a dedicated JSON database together with a simplified query API locally? This might be preferable to an SQL database as it would be a lot simpler for simpler or smaller scale requirements.

    In theory, a developer could request a unique database identifier, or use the URI as a namespace to ensure that no storage naming conflicts arise.

    Graham
    0
  • QUOTE (Tobias @ Dec 2 2008, 04:07 PM) <{POST_SNAPBACK}>
    Do you know CouchDB? http://incubator.apache.org/couchdb/


    Yo Tobias and welcome,

    heard of it, but hadn't thought of it in this context. At least as pertinent as persevere. Cross the two and we should have the starting point we need to propose an API.

    thanks for posting!
    lloyd
    0
This forum is locked.

Recent Posts

in Feature Ideas