[Dev] Feedback on repository documents requested

[Ted Leung]

A list of supported data types has been on my to-do list for a while.  
I think this is going to get done for 0.5, as well as some other 
documentation/specification type tasks.

Ted

On Oct 22, 2004, at 5:25 PM, John Anderson wrote:

> I just looked at Ted's document and noticed that it does use parcel 
> XML to document the repository -- so my comments below don't apply to 
> his documentation -- I think Ted's document does a good job of 
> addressing my concern and doesn't quite match my reading of Andi's 
> comment.
>
> I have two suggestions for Ted's document:
>
> It would be useful to have a list of datatypes that the repository 
> supports, with examples in parcel XML, with an eye to which datatypes 
> map onto Python datatypes and which don't, and which Python datatypes 
> can't be represented in the repository. Note common stumbling blocks, 
> i.e. you can't mix references and literals in lists and dictionaries. 
> Document the combinations of using the different types of cardinality. 
> Document the difference between initial values, default values (now 
> deprecated), no values, None values, empty lists, etc. would also 
> help.
>
> It would be useful to include more in depth discussion of single refs 
> vs. bidirectional refs, how they are implemented and the consequences 
> of using them.
>
> I think it would be useful to put his document on the wiki (if it 
> already isn't there) and continuing to make minor improvement after 
> 0.4
>
> John
>
> John Anderson wrote:
>
>> I think Andi is missing an important point a here:
>>
>> Almost all the use of the repository by real people today, and in the 
>> foreseeable future, is via parcel XML and the a small amount of 
>> repository API. Learning how to use the repository from the 
>> perspecive of parcel XML is essential to learning the repository in 
>> real world applications.
>>
>> I think it's unfortunate that we ended up with two different XML 
>> formats, parcels and packs, which have a nearly idential purpose -- I 
>> think they should have been combined, and if not, I think that parcel 
>> XML belongs more to the repository than to Chandler, CPIA or any 
>> other project.
>>
>> John
>>
>> Andi Vajda wrote:
>>
>>>
>>>> 1) A general overview of how the repository fits in with the rest 
>>>> of Chandler would be helpful. I think it's implicit in the doc that 
>>>> the repository can be used separately and also as part of the 
>>>> Chandler PIM. Would be clearer if this were made explicit. Thus, 
>>>> this doc addresses both people who want to develop parcels on top 
>>>> of the Chandler PIM and also parcels completely independent of the 
>>>> Chandler PIM.
>>>
>>>
>>>
>>> Actually, developing parcels is a Chandler activity, the repository 
>>> doesn't understand parcels, they are a funtionality introduced in a 
>>> layer above the repository.
>>>
>>> Andi..
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> 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
>
----
Ted Leung                 Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42