> It is proposed to replace, yes, but I know that it is not complete at
> the moment. I just wanted go get it out there before the current REST
> interface is finalized.
If that is the case, then I do have a few concerns I noticed when first
reading the proposal. In general, these concerns stem from the the
design principle stated on the wiki page: "There should not be big
methods with lots of parameters, but rather a bunch of small ones with
very clear purpose." Many of these are very convenient, but relying on
them exclusively raises questions.
The problem is that the 'methods' in the proposal conflict with the
current preservation/versioning model in Fedora. Datastream versions
contain a content stream, as well as relevant metadata such as checksum,
label, etc, etc. These are preserved together as a single unit. It
needs to be possible to update *both* the content *and* the properties
in a single, atomic operation. In the proposal right now, it is
impossible to do so. In addition, the implications of these
fine-granied operations on datastream versions is unclear.
For example, what does a POST
to /objects/{pid}/datastreams/{dsID}/properties/checksum really mean?
Does that mean that a new datastream version could be created? Does it
mean that a value in *current* datastream version is modified? (without
creating a new version or audit entry)? If a client intends to modify
both datastream content as well as datastream properties, does this
imply that it MUST first change datastream content, then change
properties? What happens if a client dies/fails between requests? What
happens if another thread/process modifies the datastream between
requests?
With datastream operations, it would appear that if the client just
wanted to make one operation/change, then everything is OK and easy. If
the client needs to make changes to content AND properties (or just
multiple properties) of a datastream, then this API makes it impossible
to for Fedora to preserve that change set as one datastream version.
That is what I mean when I say "conflict with the current
preservation/versioning model in Fedora".
Other than that, A few quick additional items I noticed:
- There seems to be no way to ingest a fully-formed object
- It is not clear how one would get/export an object in a specified
serialization format
- There should be a way to DELETE a content model from an object.
Overall, I recognize that exposing various aspects of a fedora object as
fine-grained resources can be very convenient and make certain tasks
easy. However, I believe that the consequences as they relate to
Fedora's preservation model need to be made clear.
-Aaron
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
