Framework modularity (was Re: [Dev] UIDMap, osaf.app and KindCollections)

[Morgen Sagen]

On Feb 3, 2006, at 2:04 PM, Morgen Sagen wrote:

> The ICalendar import/export code needs to be able to look up  
> CalendarEvents based on their icalUID attribute; up until now  
> maintaining this lookup mechanism has been the job of the UIDMap  
> class in the sharing layer.  However, having that code live in the  
> sharing parcel creates unwanted dependencies on that parcel, and it  
> would be cleaner to have that code live in pim.calendar.  In  
> addition, in the time since UIDMap was written, the repository's  
> support for indexing has improved to the point we could replace  
> what UIDMap does with an index on the CalendarEvent extent  
> (KindCollection).  There is currently a CalendarEvent  
> KindCollection living in osaf.app, but I think it makes more sense  
> to move that collection to pim.calendar, so that code just wishing  
> to use the calendar isn't tied to the osaf.app parcel.  So I am  
> proposing we move the 'events' KindCollection from osaf/app/ 
> __init__.py to osaf/pim/calendar/__init__.py (and change all  
> (three) references to it accordingly).  There were already several  
> +1 votes in IRC for this today.
>
> Going through osaf/app/__init__.py I see five other  
> KindCollections:  notes, locations, mail, emailAddress, and  
> scripts.  Should we also move those collections to live in their  
> corresponding parcels?

I moved the events collection from osaf.app to osaf.pim.calendar this  
morning, and will be moving other collections soon.  However, in  
addition to the various KindCollections within osaf.app there are  
also some 'well known' items like 'me' (the Contact representing the  
Chandler user), the All collection, and the Trash.  Unfortunately,  
from a modular-framework standpoint, I now realize having those items  
in osaf.app is undesirable -- it means that we have lots of code that  
depends on osaf.app, which won't fly if we hope people will be  
creating other applications using our framework.  osaf.app defines  
Chandler-the-application, and that parcel wouldn't be used by someone  
writing their own application.

So I think we need to examine each item defined in osaf.app and see  
how they are used.  If there is code that references an osaf.app  
item, that item should be moved to a more appropriate parcel. For  
example, the 'currentWebDAVAccount' Reference item could move to the  
sharing parcel (that would be its new 'well known' location).   
However, the CosmoWebDAVAccount sharing item that we ship with out of  
the box (that the 'currentWebDAVAccount' Reference item points to)  
would be an appropriate item to live in osaf.app like it does. The  
webserver and servlets are also good candidates for osaf.app; I  
believe they are not referenced directly by any code, but are found  
via their class.

There are some collections, such as 'eventsWithReminders' that are  
bit harder to place; that collection is only used by  
osaf.framework.blocks.ControlBlocks and osaf.views.main.mainblocks.   
So does it belong in osaf.pim.calendar, or should it live in CPIA?   
Also, where should the sidebarCollection live?

The WelcomeEvent item should live in osaf.app, however  
osaf.views.main.summaryblocks shouldn't directly refer to it.   
Instead, I propose we add a Reference item (named "FirstTimeItem" or  
something) to osaf.views.main, and have osaf.app make it point to  
WelcomeEvent.  That way, summaryblocks doesn't need to know about  
osaf.app, and some other application could choose their own item to  
display when their application first runs.

Now is the best time to straighten this out (early in the release  
cycle).  I volunteer to modify all the code that currently depends on  
osaf.app.  The list of items currently in osaf.app, plus my first  
guess at where they each should live, is here:

    http://wiki.osafoundation.org/bin/view/Journal/FrameworkModularity

If you have an opinion about where a particular item should go,  
please add it to the "Notes" column for that item on the above wiki  
page.  I just want to make sure folks basically agree with the goal  
of not having osaf.app be a dependency for framework code.

~morgen