>> We don't yet have a real server, so we're not
quite at that
>> stage yet.
>
> Thanks for the response. I'm curious how it supports
concurrent
> editing and data persistence without a server.
You bet, let me try to describe how it works now...
Right now we're storing all the data on the server in what
amounts to
one long transaction log file. When you create a new item
on the
client, the JavaScript code creates a little JSON-format
text packet
that describes the transaction. The client sends that text
packet to
the server, and the server appends the packet to the log
file. Same
thing whenever a user changes any attribute of any item.
Each new attribute value gets a unique id. If I edit the
Kermit item to
set the color attribute to "green", then there
will be a new unique id
associated with that entry, something like this:
{id:XYZ,
user:Brian, timestamp:"2006-09-18 16:44:28",
item:Kermit, attribute:color, value:"green"}
If you come along and change Kermit's color to
"aqua", that creates a
new entry, which is marked as a replacement for my old
"green" entry:
{id:QRP, replaces:XYZ,
user:Jon, timestamp:"2006-09-19 13:11:33",
item:Kermit, attribute:color, value:"aqua"}
Let's say there's also another user, Amy. Amy might also
be editing
Kermit at the same time you are. Amy would still think
Kermit is green,
because she hasn't yet seen your change. She might
independently change
Kermit's color from "green" to
"blue". Her entry looks like this:
{id:ABC, replaces:XYZ,
user:Amy, timestamp:"2006-09-19 13:11:33",
item:Kermit, attribute:color, value:"blue"}
At this point the transaction log contains all three
entries: XYZ, QRP,
and ABC. Entry XYZ is no longer considered as binding,
since the other
entries mark XYZ as having been replaced. But QRP and ABC
are both
still binding, since they were made concurrently and neither
one
replaces the other. So at this point Kermit is both
"aqua" and "blue".
When a new user opens their browser and looks at that
page, the
OpenRecord JavaScript code figures out Kermit's current
color by reading
the entire transaction log and seeing what entries are
applicable.
The transaction log approach is not scalable, but it has
worked nicely
for prototyping. There's a 4-minute section in our
screencast that
shows how this all looks from a user's perspective:
http://openrecord.org/screencast/2006-02-21/O
penRecord.html?movie=5
> What are you thinking the server will be written in?
To get a server up and running quickly, with all the
flexible data
features that we want, I think the best bet is to build on
top of Adam
Souzis's RDF server tools, Racoon and Rx4RDF. I think
those tools are
written in Python, although I think sites that use those
tools can be
written using RxSLT, XSLT, and RxUpdate.
There's more info at Adam's web site, although the server
seems to be
down right now:
http://www.liminalzone.or
g/
~ Brian
____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/
openrecord-dev mailing list
openrecord-dev lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev
|
I
have a million little tool ideas I'd love to implement with
it.
The feature, in my view, that would make it "the
cat's meow" would be
a RESTful XML interface (
Brian
____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: