[Dev] parcel modularity... not

[John Anderson]

We've discussed the need for a simplified organization for parcel 
directories, which are a complete mess today as you point out. If I 
remember correctly, Katie proposed doing it sometimes after 0.4. This 
might address some of your concerns.

John


Kapil Thangavelu wrote:

>On Fri, 2004-08-27 at 10:21, John Anderson wrote:
>  
>
>>I thought you raised some really great issues, which we need to address:
>>
>>Kapil Thangavelu wrote:
>>
>>    
>>
>>>hi folks,
>>>
>>>i've been experimenting with not loading some of the optional parcels
>>>(zaoboa, stockquote, and demo). however my experiments revealed that
>>>parcels are intimately tied to each other, for example the
>>>view/main/parcel.xml explicitly refers to every parcel present in the
>>>ui, such that disabling the load of say the stockticker parcel, still
>>>causes chandler to barf while parsing the main/parcel.xml due to the
>>>explicit ref, ditto for location.xml. 
>>> 
>>>
>>>      
>>>
>>I suspect that this happens to be true because the menus refer to these 
>>optional parcels
>>    
>>
>
>
>yes, thats exactly the issue, but the real question is can these menus
>be filled/extended by the relevant parcels themselves? if so how? 
>
>  
>
>>>i guess i'm wondering if its a design goal for parcels to be modular
>>>units, and if so is it just a bug that things like views/main is
>>>building up a global views as opposed to setting them up and letting the
>>>respective parcels fill them. 
>>>
>>>also its not clear if parcels are intended to be discrete units, why the
>>>core parcels are split into many subparcels scattered throughout the
>>>parcel hierarchy.
>>> 
>>>
>>>      
>>>
>>parcels are intended to the a unit of replaceability. In practice, 
>>however, they also end up being a unit of work that a particular person 
>>does, and as a result this impacts what lives in a parcel. I think we 
>>should probably make a pass through all the parcels and decided if the 
>>units of division really makes sense.
>>    
>>
>
>even as a unit of work, unifying their location to resemble the intended
>goal of replaceability is doable. as it is to find the parts for a
>particular semantic parcel requires delving into a number of different
>parcels across the osaf packages. coming up with a definitive/suggested
>structure for a content parcel such
>
>as 
>contentparcel/
>  views/
>  model/
>  code 
>
>would be helpful, for example at the moment for the mail parcel i need
>to dig into many different directory structures..
>
>/parcels/osaf/contentmodel/mail - for the schema
>/parcels/osaf/mail - for the code
>/parcels/osaf/views/main/parcel.xml - for the registration into global
>menus
>/parcels/osaf/views/content/parcel.xml for the views defined
>application/dialogs - for the account dialogs
>
>the distinction between application and parcel living code is pretty
>unclear to me.
>
>their is an implied issue of code ownership in your reply which i also
>find troubling, reorganizing chandler to something like this structure
>would take 2-3 days, but if there are ownership issues its not clear its
>going to happen without alot of concerted effort. getting some standards
>together for people to follow when constructing parcels, will go a long
>way towards mitigating, imho. but the issue is still troubling, and i
>hope i'm just over implying, as there are still a few far reaching
>changes that need to be effected in the code base, imo. as an example,
>scattered throughout the chandler code base are various usages of the
>logging package and print statements, unifying this logging with some
>basic infrastructure to something sane and configurable is on my todo
>list, but its a far reaching change, is this something that i would have
>problems in getting a patch integrated for because it affects many
>people and no one wants to take responsiblity for doing something which
>would affect other people's code? or another example, there are several
>uses of synchronous apis in the code base, instead of twisted.
>
>  
>
>>>regarding the issues of loading and unloading parcels i brought up on
>>>irc earlier today, i think the parcel load/unload issue and
>>>corresponding repo items question, is better defined by a different
>>>notion, namely parcel lifecycles, and that currently there is only one
>>>state for a parcel in the application, namely loaded but it would be
>>>nice to incorporate active and inactive as a parcel might dealing with
>>>aribtrary resources outside of content items in the repository.. for
>>>example shutting down a webserver, or deactivating zaobao
>>> 
>>>
>>>      
>>>
>>I agree, it makes sense not to load all the parcels, expecially in the 
>>situations you bring up.
>>    
>>
>
>as a stop gap solution i submitted a patch for parcel not loading, which
>morgen integrated, if you put a noload file (touch noload) in a parcel
>directory it won't load the parcel. the functional use of this without
>additional hacking of the core is limited at the moment due to the
>issues already stated in this discussion. its a hack, imho, but it
>serves for the moment.
>
>
>cheers,
>
>Kapil Thangavelu <hazmat at objectrealms.net>       Vision Implemented
>objectrealms.net <http://www.objectrealms.net>
>
>  
>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>