Sounds interesting, but, are you going to work on this? OSAF staff is
limited on resources and time, they are having a hard time keeping with
small bug fixes why do you think they will even look at this? Well, I
seriously don't believe so. I appreciate your effort, but more documents are
the last thing Chandler needs now. Chandler needs action... Chandler's
development must move towards agile methods - small and frequent updates.
When we reach a good development community, proposals might become viable,
however, I'm sure your document will stay there for a looong time waiting
for someone to take action on it - unless you start doing something ;)

On Fri, Mar 14, 2008 at 10:00 PM, Brian Kirsch <[EMAIL PROTECTED]>
wrote:

> Hello,
> I have updated the proposal to include more detailed information
> regarding
> the Notification Job Scheduler.
>
> http://chandlerproject.org/Notes/NotificationArchitectureProposal
>
> Thanks,
> Brian
>
>
> On Mar 14, 2008, at 11:16 AM, Brian Kirsch wrote:
>
> > Hello,
> > I have completed the Notification Architecture proposal which can be
> > found at:
> >
> >  http://chandlerproject.org/Notes/NotificationArchitectureProposal
> >
> > I have also linked to the proposal from the Notification Mockups Page:
> > http://chandlerproject.org/Notes/NotificationsMockups
> >
> > A brief highlight of recommendations include:
> >
> > * Adding the ability for a user to specify his or her timezone
> > during the sign up process and the ability to change that timezone
> > in the Account Preferences.
> >
> > * Creating two new Atom projection URI's to support notification
> > changes and forward notification queries.
> >
> > * Augmentations to the Service layer to
> > based on a time range return all items in a collection that have a
> > start time (events) or reminder time (alarms) that falls with in
> > the range.
> > based on a time range query for a collection return notification
> > objects that represent the changes per item with in the range.
> > Record in real time changes made to an item or a collection (via a
> > Hibernate / Spring abstraction) to modification database tables
> > including the previous and current values.
> >
> > * Expanding the User Preferences logic to store settings for push
> > based listeners (EMAIL, SMS, XMPP) including which collections to
> > push, the type of notifications (forward or modifications), and how
> > often.
> >
> > * Incorporating a Job Scheduler in to the Cosmo Architecture. The
> > Scheduler will have jobs that awake at specific intervals,
> > determine which users want notifications, query the Service layer,
> > and pass the results to registered listeners (EMAIL, SMS, XMPP).
> >
> > * Adding new tables to the Cosmo schema and wrapping the database
> > insertion and query logic in a Hibernate / Spring abstraction
> > layer. The tables would persist changes to items / collections as
> > well as additions and removals. The appropriate table columns would
> > be indexed for fast query of modifications made in a given time range.
> >
> > -Brian
> >
> >
> >
> > Brian Kirsch
> > Senior Web / Desktop Engineer and I18n Guru
> > Open Source Applications Foundation
> > http://www.chandlerproject.org
> >
> >
> >
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> >
> > Open Source Applications Foundation "chandler-dev" mailing list
> > http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev

Reply via email to