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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
