> > 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.
I think that executing multiple operations in series as part of a single logical change that would otherwise be preserved as a unit might be an anti-pattern in general (some of these preserved versions would necessarily be inconsistent with the desired end state). However, in my own use case, I would say that 90-99% of all datastream modifications do involve only *one* change - and in that case, this API proposal fits very well by providing an additional, lightweight, easy to use tool. Some of my most common use cases are: 1) updating datastream content, keeping all properties the same 2) changing datastream state, keeping content and other properties the same 3) fixing datastream MIME type, keeping content and other properties the same A less common (but important) use case for me involving changes to both content and properties is updating content, label, and mime type. I would want to to perform that change one atomic operation. > I do not propose to change things without creating an Audit entry. What > made you think I meant that? I was not sure if the granularity of these operations had any implications on auditing. > > 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? You're right - it does not matter. It may have implications on what the inconsistent intermediate versions would look like, but does not present a fundamental difference. This has been a delightful topic, Asger. Thanks! -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
