[Dev] parcel modularity... not

[Kapil Thangavelu]

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20040827/dad44b32/attachment.bin