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