Wednesday, February 29, 2012

Anyway, software break is over, lets consider something

Like dropping a new bookmark onto the bookmark table. The machine, as it stands, would in the default just append the book mark table. Appending is a natural consequence of forward looking nested bound objects with skip ahead counts. So the Lazy Json is: bookmark{newname,newurl,..}. Running that into the machine, the machine should just append it to the bookmark table, right?

The first instance of namespace is the table, or in NoSql language, a graph. So we have a semantic agreement among us all, the user gets a local namespace that is persistent and needs no prefix to identify its location. By the way, the machine simply opens a graph context on the table, and the ready set row pointers are set up for call back on precompiled, high speed bind, sql operators. Once the bookmark table is open, this thing is blindingly fast and accurate.

At some point, Json will want us to say, #bookmark, to identify the fact their is no higher namespace reference. But don't need it now, do we. Want to recover a bookmark? Well, bookmark.joe.* is the informal, query, the one I have been using. But internally, that is @joe.*,bookmark as the internals is set up for a binary lambda operation? Right? The missing thing in Json, the lightweight 'Tree Climb' we might say, the thing we do with Doms. Well this machine has that in spades. That is the idea, cruise the big graph.

So, lets set a target, make table names first and foremost a space reserved for the local client and see what happens. Then we market this thing as the personal, Json natural client name space, as an easy to use Json compatible adjunct to the browser. How about that! I can do that in a jiffy.

But wait!!! What abo that informal query? Am I going to war with the quotes? We have to say bookmarks."joe" to differentiate with bookmarks.title; and we can match otherwise using position. Then that leads to bookmarks$url to pick off one field in a bookmark, regardless o0f position? I have little clue about some of this, except to say, whatever the ultimate standard, there will be a Lazy J version of it. In the meantime, I can make things up.

No comments: