Could APP not just be extended and namespace to meet your need?

At least then, even if, yes, we're using some niche namespace for the
specific functionality you mention here, it's built on a foundation
that isn't so /totally/ library specific that others could pick it up
and use it on top of their existing systems (or, at the mininum, the
parts they support).

Out of curiousity, was this used much in Z39.50? Which actions were
used the most? What sorts of services was it used in?
-Ross.

On 9/29/06, Rob Sanderson <[log in to unmask]> wrote:
> To add to Janifer's reply...
>
> 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.
>
> 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. But
> 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 :)
>
> Rob
>
>
> On Fri, 2006-09-29 at 09:56 +0200, Janifer Gatenby wrote:
> > This question was posed several times. Update mechanisms like WebDav that use HTTP PUT, POST and DELETE rely on HTTP diagnostics and it seems quite an effort to get influence to create new diagnostics here. HTTP diagnostics are too limited for updating metadata. Most update mechanisms are focussed on document updating and sharing documents. They miss elmenets that are important to metadata catalogues and repositories such as aligning control numbers, authority linking, linking multiple language versions etc. In addition, the focus is on the client having update power, whereas with SRU update, the power is more or less shared. The client is making a suggestion and the server ingests it as best suits the database, hence the need for interactive diagnostics and the employment of POST rather than the more specific PUT, etc.
> >
> > Janifer Gatenby
> > OCLC PICA
> >
> > ________________________________
> >
> > From: SRU (Search and Retrieve Via URL) Implementors on behalf of Erik Hetzner
> > Sent: Fri 9/29/2006 3:13 AM
> > To: [log in to unmask]
> > Subject: Re: New draft of Record Update
> >
> >
> >
> > At Tue, 26 Sep 2006 17:00:22 -0400,
> > "Ray Denenberg, Library of Congress" <[log in to unmask]> wrote:
> > >
> > > A new draft of the Record Update protocol has been developed by the SRU
> > > Editorial Board.
> > > http://www.loc.gov/standards/sru/record-update
> > >
> > > Please review and comment by October 12.
> >
> > Hello all,
> >
> > I know that I am a bit late to this game, but given the great uptake
> > of SRU (as opposed to the SOAP based SRW), could somebody explain to
> > me what this solves that could not be solved with pure HTTP? This is
> > an almost classic problem for:
> >
> > a) URIs that define a unique record, and perhaps a particular version
> > of that record.
> >
> > b) the HTTP verbs define the operations: PUT (replace in this
> > proposal), POST (create), DELETE (delete).
> >
> > c) the HTTP response codes define a great number of possible statuses,
> > including success (200), failure (4xx), delayed (202 Accepted), etc.
> >
> > d) other response information, if required and it is not possible to
> > fit into the HTTP headers, can be wrapped around the srw:record
> > element.
> >
> > A solution of this sort seems to me to be simpler and easier to
> > implement, especially for those who have currently implemented SRU but
> > not SRW.
> >
> > Best,
> > Erik Hetzner
> > --
> > Erik Hetzner
> > California Digital Library
> > 510-987-0884
> --
> Dr Robert Sanderson
> Dept of Computer Science, University of Liverpool
> Home: http://www.csc.liv.ac.uk/~azaroth/
> Cheshire: http://www.cheshire3.org/
>
>