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

[John Anderson]

Lisa Dusseault wrote:

> I don't think we can always afford to "upgrade the item to the new 
> schema".  We can do that with the local repository copy, but not with 
> the shared copies on the server -- that would cut out from sharing any 
> client that hadn't yet upgraded code.  So there needs to be constant 
> transformation between the local schema and the shared schema (aka the 
> "old schema", aka the "interoperability schema"), every time a synch 
> happens to a server.  (Even in a P2P system architecture, there would 
> need to be constant transformation between the local schema and the 
> peer's schema.  Typically this responsibility would fall to the client 
> with the newer code and awareness of both schemas.)
>
I agree that having a server keep multiple copies of data to match 
different versions of schema makes sense.

> I'm not sure we understand each other around "making sure that version 
> of the schema is available".  In my understanding, we could easily 
> make the new version of the schema available to older clients but it 
> would be no help.  The schema doesn't tell you what each attribute 
> means.  Older clients only know the meaning of older versions of the 
> schema (or perhaps older clients can be aware of an interoperability 
> base schema which almost never changes, but only gets extended).
>
All I was saying is that the data and matching schema needs be both be 
available to whoever is using the data, since Chandler needs the schema 
to use the data.

> Forcing old clients to obtain new schema with enough information to 
> display the new schema items would theoretically be possible if 
> everything were data driven.  However, this would now be tantamount to 
> forcing them to upgrade as soon as one other person they share with 
> upgraded.  New features would spread like a virus.  For that matter, 
> it could be a virus.  Maybe I'm describing a straw man here, rather 
> than anybody's real position, but if so it's a failure of 
> understanding so please fill me in...
>
> Lisa
>
> On Nov 15, 2004, at 2:53 PM, John Anderson wrote:
>
>> 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
>>
>>
>