On Sep 29, 2006, at 5:02 AM, Rob Sanderson wrote:
> In order to create a full over-the-wire remote information system
> management protocol, there's a lot more actions required than just
> create, replace, delete.
> For example, index/unindex, cluster, classify, transform, etc. etc.
> For this, you need a lot more than the simple http verbs.
Yes, but conceivably some of these could be expressed as an update/
PUT. If you take the red pill and imagine an index as a resource, a
record could be PUT to the index. New indexes could even be created
with a POST, etc...
curl -X PUT http://loc.gov/index < no9910609.xml
Or perhaps more interestingly (for some):
curl http://loc.gov/no9910609 | curl -X PUT http://loc.gov/index
and some of these could possibly be seen as a representation of a
given record or a GET
As far as indexes go Brian Cassidy has actually implemented a RESTful
webservice API to Lucene as lucene-ws  and the solr  project
has a somewhat similar API. So I guess in a way there is room for
another not-really-restful api :-)
> I agree that there are existing update mechanisms, and if APP (for
> example, which as Ed pointed out didn't exist when we first looked at
> Update) could fulfill the requirements, then re-inventing the
> wheel, or
> even trying to compete, would be absolutely the wrong thing to do.
> I don't know if our community has enough traction to get the necessary
> changes made, in that regards? I'd welcome further comments on this
> approach :)
I'm not really familiar with the requirements (especially ones like
index, cluster, classify) so it's hard for me to say with confidence
how well the Atom-Publishing-Protocol  itself would accommodate
what you want to do in Update . I can say that:
- APP allows for records to be created, read, updated and deleted
- APP has facilities for authentication.
- APP uses HTTP status codes to return diagnostics but I would be
surprised if most desired diagnostics could not be mapped to a class
of HTTP status codes. The response body could be used to bundle more
detailed diagnostics if necessary. I had to review RFC 2616 Section
4.3  to see if HTTP allowed for message bodies in error responses.
- APP is able to transport any type of XML encoded record as long as
it's well formed.
- I'm not entirely sure how well APP would support versioning. It
could be expressed in REST of course as a representation of a given
record like http://loc.gov/no9910609/version/3 or somesuch.
If there is genuine interest I could look into this further and
sketch out some examples. It's true that changing APP will be much
more difficult than changing a zng webpage at the LoC. But even with
APP's youthful appearance there is already an example of how to
extend the protocol --so perhaps this isn't as a huge an issue as
you might imagine. I think the real benefit here is joining a larger
community of developers and bridging the divide between library
computing and the web community at large (as Ross and Mike pointed out).
A real advantage in developing a niche standard instead of using
something like APP is security through obscurity...which probably has
some appeal given Update's role :-)