Monday, February 27, 2012

Now what with the Json engine

Well, the main thing we want for for clients to drop items onto their browser widgets, tag items, retrieve them all using the client's own names space. So it would seem my value added would be improving he name space making Sqlite3 index system available to the client. The browse side is already populated with tool and widgets, it already talks Json, so this engine code is building into that existing market. The browser folks have great libraries, a multitude of ways to render Json. Let them do their job.

Nut names space for the client, that is where the advantage, but naming has to be naturally to the client and still fit into the Json framework. that is the big Hmm... Imgisoft is on the case. I have been browsing the forums and user groups, what they are using, getting idea. Like this one guy has a few lines of c code that works with Sqlite, giving sqlite3 the natural ability to store IP4 and IP6 addresses in the same record format. But we are not even that far, we still have to figure out naming space when the user is dealing only with local data.

It is the totality of it, the desire to get a Json naming custom, or reference point for applications. I need a target, a vision of how a client might just want to deal with a gaggle of bookmarks, can he just drag them onto the engine and have it sort things out? How? Hmm..

Think about dragging a bunch of bookmarks over to the engine. It can do that because browsers can export Json strings of bookmarks. The engine can store them, keep the serialization format, and index on any one of the bookmarks, on any column. But is there a naming standard? Do clients all agree that the name bookmarks means something. And is that always going to be the cosument name for bookmarks? The industry has standards here, but the connection is never created until the standard is natural to the client, this is an information interface.

No comments: