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

[Lisa Dusseault]

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'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).

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
>