[Design] 0.7 Chandler scheduling phasing proposal

Sheila Mooney sheila at osafoundation.org
Wed Feb 22 22:13:02 PST 2006


On Feb 22, 2006, at 6:50 PM, Philippe Bossut wrote:

> Hi Sheila,
>
> Continuing my comments on Phases:
>
> Sheila Mooney wrote:
>> *+ Phase #1*
>>
>> *-> Goals*
>> - get something experimental up and running quickly
>> - use infrastructure that exists today
>> - free-busy -> reduce depencies on requiring backend caldav free- 
>> busy report as well as any new gui widgets (special panel in  
>> sidebar).
>> - notifications -> simple solution for both outbound and inbound  
>> notifications that doesn't rely on much email work
>>
>> *-> Free-busy*
>> - use the existing publish and subscribe workflows to publish and  
>> subscribe to free-busy information
>> - upon publishing, a 3rd url will be returned for the free-busy  
>> info (fake free-busy not using CALDA reports - just calculated  
>> using the published calendar)
>> - subscribing works the same way as today
>> - when subscribing to a free-busy calendar, it appears in your  
>> sidebar just like all other shares
>> - free-busy shares are read only
>> - we would use the same sharing icons as today
>> - the detail in the calendar would appear like any other calendar  
>> lozenge - with no event title in lozenge - blank detail view  
>> fields (except for date/time)
>> - you can overlay calendars exactly like you do today
>> - unpublish/resubscribe works using the same workflows
> Very bare bones but will be a good proof of concept.

Exactly.

>> *-> Event Notifications(Invitations)*
>> - make stamping work for sending an event notification
>> - stamp event as mail and send
>> - fix a number of the existing stamping bugs
>> - when you stamp an events as a mail, copy the date time  
>> information into the notes fields
>> - dnd mail, ics files, text into Chandler to create an event
> Stamping as a notification mechanism will have some issues (as we  
> discussed yesterday, see http://wiki.osafoundation.org/bin/view/ 
> Projects/InviteEngineering) but as long as we go in there with full  
> knowledge of those limitations, that's OK. We should start thinking  
> about the real complete solution though (very likely post 0.7).

Yes, we realize the limitations if we go ahead with the stamping  
solution for 0.7 and understand the concerns you and Bryan have. As a  
result, I thought we decided yesterday that we would start discussing  
the issues and the more complete solution soon (during 0.7). I don't  
think we should wait until post 0.7 so we plan to move forward with  
that.

>
> On dnd, I understand that we are talking about dnd of emails from  
> another email clients to Chandler. Is that what you mean?

Yes.

>> *+ Phase #2*
>>
>> *-> Goals*
>> - free-busy - use CALDAV and look at improvements for handling  
>> list of free-busy calendars
>> - event notifications - make progress on some of the email work  
>> for 0.7 and focus on workflows for Chandler-Chandler users
>>
>>
>> *-> Free-busy*
>> - hook up the free-busy view to the free-busy backend - using  
>> caldav free-busy report
>> - investigate different sidebar area for managing free-busy calendars
>> - individual design proposals TBD
>> - iterate on different calendar displays
>> -  individual design proposals TBD
> Quite a bit of design work but I've seen good ideas floating  
> around. Seems we can converge.

Yes, once we have the bare bones version up and running, iterating on  
this will be more productive.

>>
>> *-> Event Notifications(Invitations)*
>> - receive email in Chandler then you stamp as event (this might  
>> partially work for phase #1 but we may have bugs that block this)
>> - sending and receiving an item in Chandler - event urls would  
>> also be an alternative solution
>> - a user can receive and item and it will be automatically updated  
>> on their calendar
> Yes with caveats (possible issues when an event is received and  
> also shared at the same time). See http://wiki.osafoundation.org/ 
> bin/view/Projects/InviteEngineering again for further discussion.

Yes, we understand the issues here.

>> *+ Phase #3*
>>
>> *-> Goals *
>> -  add iMip support for event notifications     -  iron out snags  
>> in free-busy workflows
>>
>> *-> Free-busy*
>> - ? potential bugs/enhancements tbd
>>
>> *-> Event Notifications(Invitations)*
>> - sending iMip requests
>> - receiving iMip requests
>> - dnd iMip invitations into Chandler
>> - handling updates - between Chandler-to-Chandler sharees
>> - handling updates - between Chandler-to-Chandler users (?maybe)
>> - maintaining persistent copies of updates (versions)
> iMip may or may not be implemented (assigned to Grant). That's  
> still under discussion.
> On Chandler-to-Chandler sharees, I was thinking, instead of emails  
> for notifications, one could imagine some use of RSS instead. So no  
> message to create in that case and the receiver gets an RSS atom  
> that tells him/her that event foo has been added/edited to shared  
> collection bar.
> I know, that's a *new* feature (not really a simplification) but  
> something I thought about and always forgot to mention in meetings...

I suspect we will do "some" iMip. We just need to figure out what  
that means. As far as your alternative proposal is concerned we  
should start a separate thread on the design list for this discussion  
so it isn't buried in this email.

>
> Cheers,
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design



More information about the Design mailing list