Sharing and attributes (Was: Re: [Dev] isPrivate: never-share flag)

[John Anderson]

I think Lisa's describing the schema evolution problem, which has a 
number of subtle of pitfalls.

If we have an item that depends on a certain version of the schema, then 
we probably have to make sure that version of the schema is available, 
i.e. it should also be shared. If I have a newer version of the schema 
on a machine and get a shared content item from an older version of the 
schema then we'd probably have to update the item to match the new 
schema, otherwise the Chandler code will break because it depends on the 
schema being a correct description of the data. Unfortunately, that 
leads to two items with potentially different attributes on the two 
machines. Hopefully most of the item transformations necessary to adapt 
to schema changes can be automated, but sometimes it will be necessary 
to run a hand written piece of code to upgrade the item to the new 
schema. Also, the schema can accomodate two different items with 
different optional attributes, so a well designed schema can leave room 
for new functionality.

John

Lisa Dusseault wrote:

> Note also that to make different Chandler release versions 
> interoperate with each other over the same shares, we'll have the same 
> issues.  How will the schema on the WebDAV server be different from 
> Chandler 1.0's internal schema? (Probably not much, except for 
> CalDAV). How will the schema on the WebDAV server be different from 
> Chandler 2.0's internal schema?  Probably more so.
>
> One wild idea I had (and discussed a bit with Stuart) was to define 
> transformations between formats.  If there was some standard way to 
> spit out an item's attributes to an XML document in memory, then is 
> there a straightforward transformation to turn that into a PROPPATCH?  
> Vice versa, how about taking a PROPFIND answer (or fragment for one 
> item) and turn it into a set of attribute values?  These 
> transformations could be written as XSLT (or something else) and could 
> be stored as data.  So then the way to share a given Item is to take 
> the appropriate transformation based on that item's schema version, 
> and apply it.
>
> It's probably not really feasible for the sharing code to just ignore 
> the attributes, no matter how we did sharing.  If I create a "knitting 
> project" custom item for my "knitting management" parcel, then any 
> schema changes risk breaking sharing of that data.  So the parcel 
> developer has to keep in mind the sharing schema and at times make an 
> adjustment.  In the first version my "gauge" attribute might be an 
> integer (in stitches per inch.) In my next version I decide I need two 
> attributes, one for  "stitch-gauge" and one for "row-gauge".  So as a 
> developer of a parcel, I just have to write the code to take the new 
> schema and make it spit out the old "gauge" attribute for backward 
> compatibility with earlier versions of my own parcel -- likewise the 
> new version of my parcel must understand when it sees a "gauge" 
> attribute on a shared knitting project Item.  This logic is completely 
> independent of protocol or whether the sharing data model is different 
> from the internal data model.
>
> Of course, one choice the parcel developer can make is to say that 
> backward-compatibility in the face of schema changes is not needed.  
> That's the only way I can see for parcel developers to be able to make 
> schema changes and not write code.
>
> Actually, I'm not too worried about the property/attribute 
> connections.  What I'm more worried about is when the item boundaries 
> change.  What if I decided Gauge was a complex reusable item and 
> needed to be broken out as a completely separate item?  So that in one 
> version of my parcel, each knitting-project item has an integer gauge 
> attribute, and in the next version it has a reference to a Gauge item?
>
> Lisa
>
> On Nov 15, 2004, at 2:01 PM, Morgen Sagen wrote:
>
>> On the other hand, sharing items with non-Chandler clients is a high 
>> priority, and do we think that the schema these non-Chandler clients 
>> use will exactly mirror the Chandler content model?  For example, 
>> Chandler might internally model a calendar event differently from 
>> CalDAV, and therefore the sharing layer would not "blindly" be 
>> transferring event items to and from the server; rather, this layer 
>> would need to perform transformations on the items, converting 
>> between Chandler-schema and non-Chandler-schema.  So the question 
>> becomes, what should the schema on the WebDAV server look like, and 
>> how does it differ from Chandler's schema?
>>
>> On Nov 15, 2004, at 1:24 PM, Mike wrote:
>>
>>> +1
>>>
>>> John Anderson wrote:
>>>
>>>> I've been hoping that maybe we could handle the name issue in the 
>>>> view, so that it would be possible for the sharing transport layer 
>>>> not to know anything about the data that's being shared -- keeping 
>>>> all attributes and the UUID of the items the same on all the 
>>>> machines that have a copy of the item.
>>>
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev