Hi
Thanks for reading through my ideas.
On Wed, 2009-10-28 at 14:40 +0100, Aaron Birkland wrote:
> > 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.
I have responded to said questions in the text below. It turned out you
pointed out some problems I had simply not thought of.
>
> 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.
You are quite right. I have simply not thought of the number of versions
that would be created from doing these operations in a series.
>
> 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)?
I actually does not remember if you can change the checksum on a
datastream today. If yes, then it should behave the same way. If not, it
should return a 403 error.
I do not propose to change things without creating an Audit entry. What
made you think I meant that?
> 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?
Why should the order matter?
> What happens if a client dies/fails between requests? What
> happens if another thread/process modifies the datastream between
> requests?
Same as today, if you used the methods to first change the content and
then the properties. The current REST method would allow you to do this
task in two separate 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".
I understand, and you are quite right.
>
> Other than that, A few quick additional items I noticed:
> - There seems to be no way to ingest a fully-formed object
No, not yet.
> - It is not clear how one would get/export an object in a specified
> serialization format
Yes, that one too.
> - There should be a way to DELETE a content model from an object.
That is a total oversight. That one I will add immediately.
>
> 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.
Thank you for making them clear to me.
Fedora, while lacking transactions, needs methods that can change all
the relevant properties on a datastream in one invocation. Actually
changing the properties one at a time will overload the versioning
system.
Regards
>
> -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
