RE: RA modules... a crock?

There are several databases (SQL Server, Oracle 9, etc) that
can do all transactions via XML, so it is conceivable, at least
to me, that the "back end" of an ra_xml module would be
a database...

-Peter

-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@newton.ch.collab.net]
Sent: Thursday, February 08, 2001 2:01 PM
To: Greg Stein
Cc: dev@subversion.tigris.org
Subject: Re: RA modules... a crock?

Greg Stein <gstein@lyra.org> writes:

> The "plugin" concept and the *ability* (design-wise) to load them on
demand
> should be kept. But I believe we've been expecting to link them directly
in
> for a while now. We can deal with dynload later on.

OK, turns out I wrote the dynamic loading stuff a while back. I won't
erase the routine, just let it gather dust for a while. :)

> [ and don't forget the third: ra_xml! ]

I sort of have a philosophical objection to this idea. The problem
with committing/updating from XML is that there *is* no repository on
the back end.

I mean, think about our RA interface, and how ra_xml might implement it:

  * what does it mean to open() a repository URL (to xml?)? What URL
    type will cause the client to use the ra_xml vtable?

  * what does it mean to close()? or get_latest_revnum()?

  * how about when updating? does it mean anything to "report" the WC
    state to the update-editor-driver, when it's just reading an
    update from XML?

I guess it bugs me to pretend like there's a repository behind the
XML, when there isn't. Reading and writing to XML is a special case,
and is currently specified by special command-line flags, and I'm
wondering if it just shouldn't stay that way.
Received on Sat Oct 21 14:36:21 2006