>>>>> "mike" == Mike Orr <[EMAIL PROTECTED]> writes:
mike> I could perhaps see it being used to edit large data fields of
mike> some persistent object; e.g., article text. Would it lend
mike> itself to that?
Precisely.
TEXTAREA blows. That's the first thing.
So imagine you have a magazine web site, with lots of editors and
authors, spread all over creation, and just about the only common
infrastructure they have is a browser and their preferred text editor.
I have such a site. Editing "through the web" simply sucks and I've
given up all hope that TEXTAREA will ever do anything but suck. It's
fine for very, very small things.
But I publish 5 and 10,000 word essays and articles every month. And I
have a host of editors and authors who need to access this stuff over
the Web.
The site is presently powered by PHP but I'm wanting to move to
Webware. I use mod_rewrite to make clean and implementation-neutral
URLs like:
/articles/500
/articles/500/plain
/articles/500/edit
/articles/500/mail-to-friend
mod_rewrite turns these into foo.php?id=500&action=print and the like.
Which means I can switch to Webware and not break any URLs. Great.
But TEXTAREA will still suck.
It occurred to me that if I could treat /articles as "just another
directory", by wrapping a WebDAV wrapper around it, then editors and
authors could use DAV clients (including the nice support MS Office
and "web folders" has) and their preferred editor to work on content.
So far the biggest technical question that I haven't answered is how
to match DAV's locking semantics to, say, Python's DB API or to some
lock abstraction layer over Postgres and MySQL, etc. That seems to be
the tricky part.
For the rest of it, conceptually, at least, it seems fairly simple: at
some point in any WebDAV implementation, there's file handling
routines, open, close, check for locks, etc.
A WebDAV wrapper around a database would replace open() with a SELECT
and unlink() with DELETE and the like. None of which is terribly
complicated (though care must be taken to do it right generically).
In other words, though I haven't looked at code yet, I would expect a
good Python WebDAV server implementation to have cleanly separated DAV
semantics from underlying filesystem/storage semantics; if so, it
shouldn't be *terribly* hard to reimplement the underlying storage
interface to use an abstract RDBMS interface, rather than the
filesystem. (Which of course opens the question more broadly: how
generic is WebDAV and what else might it be used to wrap? LDAP? POP3?
IMAP? It's at least an interesting problem.)
Anyway, that's the idea. I don't know a lot about MiddleKit, though
what I do know about it suggests a DAVKit could use some of
MiddleKit's db abstraction and schema support to more cleverly manage
the interface between DAV verbs and various RDBMS storage systems.
FWIW, that's what's behind my question. :>
Best,
Kendall Clark
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
