REST, tiddly, architectures etc
chris...@gmail.com
Jeremy contacted a few folk (me[1], Simon McManus and Martin Budden)
to start a discussion on "defining a canonical server side
architecture for TiddlyWiki". On this list seems like the right point
for such things.
Simon suggested http://phprestsql.sourceforge.net/ as a useful tool
for generating a REST interface to server side stored resources.
It does look useful (albeit a bit too focused on the data store) but I
think it is early days yet to be talking about the implementation. I'm
not sure we yet have a clear understanding on what a "server side
architecture for TiddlyWiki" is nor what such a thing does or allows
someone to do. To demonstrate why we need such a thing, let me create
a morass of words below, that you may or may not find interesting.
If the goal is to have a server where tiddlers or things which can be
transformed into tiddlers are stored, the problem is fairly simple at
first glance: support GET and PUT on a server with reasonable names
for the tiddlers. The Tiddly can do the javascript to send them back
and forth. This function already exists in Tiddly, to many different
servers.
What about a general store for tiddlers? For multiple Tiddly
instances. Things start to get a bit more complicated. If I have one
Tiddly with a tiddler named foo and another Tiddly with a tiddler with
the same name how are they distinguished? What about multiple users on
the same server? And TiddlyWiki's that contain tiddlers from multiple
(canonically architected) servers?
This may begin to sound like a problem of identification: Each tiddler
needs to be identified in a global context. If we have global
identifiers, we need some way to lookup translations from
identification to location (akin to DNS).
If tiddlers on a server are content (rather than plugin) what happens
when someone GETs a tiddler to their own TiddlyWiki. Is that by
default a copy, or a mirror of the server side content. If the content
at the server changes, when I access the network next, should my local
content be updated? If I update my local content and want to save it
on a server should it change the original content on the server, or
create a new thing on the server which is a derivative of my thing?
Should both be possible, with some mechanism to change it?
If the tiddlers are plugins, who can GET them? who can PUT them? Where
should conflicts that happen while GETting be resolved (on the client
I hope!)? Will any plugins need a remote datastore?
What about the peer 2 peer Tiddly thing I mentioned a while ago? How
does that adjust the expectations of a server architecture?
Most of these issues are addressed to some extent in HTTP and
Hypertext in general. Tiddlers on servers + TiddlyWiki-like-things is
the web with a different (better? more interesting?) UI. Issues of
identification, authentication, access control, conflict resolution,
etc are there in HTTP.
What Tiddly provides is a sort of hypertextual composability. Plugins
from multiple servers + content from multiple servers + locally
generated stuff = lots of power, flexibility and adventure out on the
edge of the network. A server architecture needs to be dead simple to
encourage widespread use.
If we can figure out what resources are at play in the system, we can
come up with the idiom of access. Once we have that, the actual
implementation is fairly straightforward: it's just a web server, with
some URIs, right?
Is that suitably morassful? Maybe we can distill this down to some
real questions and see where to go next?
Thanks,
Chris
PS: By the way, I'm moving to the UK this weekend. I'll be in Oxford,
happy to head into London to meet up with the Osmosoft folk.
[1] I come into this picture from Socialtext, where I'm a developer. I
was the internal technical contact for Jeremy and Martin when we
developed Socialtext Unplugged (https://www.socialtext.net/open/
index.cgi?socialtext_unplugged). I was one of the primary designers of
the REST API that Socialtext presents. Unplugged can synchronize
content through it using adaptor code that Martin cooked up.
That REST API (https://www.socialtext.net/st-rest-docs/index.cgi?
socialtext_rest_documentation and http://www.socialtext.net/amo/index.cgi?the_amo_api)
has worked out very well as an interface to wikis. The URI structure
supports some wiki semantics (pages and the like) but in the end is
really just a bunch of ways of getting at stuff. If we can determine
the semantics of a Tiddly Server, then coming up with a supportive URI
structure can be pretty straightforward. Or we could just do Atom, but
I'm not sure that's a good idea, which I'll write about some other
time.
Bob McElrath
chris...@gmail.com [chris...@gmail.com] wrote:
> Most of these issues are addressed to some extent in HTTP and
> Hypertext in general. Tiddlers on servers + TiddlyWiki-like-things is
> the web with a different (better? more interesting?) UI. Issues of
> identification, authentication, access control, conflict resolution,
> etc are there in HTTP.
Yes, it does. Specifically, WebDAV. Currently ZiddlyWiki can be thought of as
a WebDAV server containing:
index.html (TW core)
tiddlers/ (directory, one file per tiddler)
though currently it's not implemented in WebDAV but uses some POST's and GET's.
So, what do you want to do that cannot be done with WebDAV? The above setup
allows per-tiddler locking (multi-user), access control, authentication.
Foreign tiddlers are easy with mapping http://your.site/#tiddler_name to
http://your.site/tiddlers/tiddler_name. It's light on bandwidth by transferring
only tiddlers. Revsion control is there (CheckOut and CheckIn methods), and
metadata can be stored (Propfind and Proppatch).
So I propose that a canonical server-side should reduce the server-side to ZERO
TW-specific code, and use published standards (WebDAV) instead. This puts all
the code on the client side.
What do you want to do that cannot be done with such a setup? Not making users
install a server-side is a giant win. Most people have access to some kind of
WebDAV share.
If I had a bit more time, I'd have done this already myself... ;) But that
situation doesn't look like it will improve soon so I'm just spouting off my
opinions instead... If someone else is interested in this route, take a look at
the ZiddlyWikiPlugin http://zw.mcelrath.org/#ZiddlyWikiPlugin. Something
workable should be possible by replacing just a couple of functions with WebDAV:
zw.loadTiddler, zw.removeTiddler, TiddlyWiki.prototype.saveTiddler,
config.commands.revisions.handler, displayTiddlerRevision,
config.commands.editTiddler.handler, config.commands.cancelTiddler.handler,
zw.refresh_tiddlers.
Basically, search for "ajax" in that file, and replace those calls with
equivalent WebDAV magic.
--
Cheers,
Bob McElrath [CERN Theory Division ]
"All wars come to an end, at least temporarily. But the authority acquired by
the state hangs on; political power never abdicates." -- Frank Chodorov
FND
Absolutely!
Personally, I think using WebDAV would be the most natural extension of
the TiddlyWiki concept.
> Most people have access to some kind of WebDAV share.
Unfortunately, I'm not sure I can agree with this assessment. Even if it
is correct, many people are not aware of it - at least a lot of people I
know (even semi-geeks) have never heard about WebDAV.
-- F.
Chris Dent
On Oct 18, 2007, at 8:44 AM, Bob McElrath wrote:
> So I propose that a canonical server-side should reduce the server-
> side to ZERO
> TW-specific code, and use published standards (WebDAV) instead.
> This puts all
> the code on the client side.
>
> What do you want to do that cannot be done with such a setup? Not
> making users
> install a server-side is a giant win. Most people have access to
> some kind of
> WebDAV share.
I don't know the answer to "what do you want to do" which is why I
asked all those questions.
Is the main perceived benefit of WebDAV that it doesn't require any
new server side code? What if there are desired transformations on
the server side, or representations of resources besides the
canonical tiddler form?
My own inclination is that WebDAV over complicates the interaction
with the web server, mostly because I'm an unrepentant REST/HTTP
bigot and WebDAV, while so much better than SOAP etc, still has too
many knobs. I also think that having some custom server code provides
a location or layer at which some necessary in the future but not
expected yet adjustments can be performed.
Since performance is not really a huge concern in this particular
environment, this is one of the problems that can be addressed by
adding another layer of indirection.
The server doesn't have to be complicated at all. I suspect we could
kick something up in Python in an afternoon of focused effort.
And there's no reason why the API presenting server couldn't use a
WebDAV store for its resources if that proved useful:
client<====>API/Transformation Server<====>Store Server
But since we don't really yet know what this thing (whatever it is)
is supposed to do, this is all idle speculation. Chatter to see if we
are all thinking about the same thing.