[Dev] parcel modularity... not

[John Anderson]

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

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

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

>cheers,
>
>  
>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>