[Dev] Content Model wiki updated
Brian Kirsch
bkirsch at osafoundation.org
Fri Nov 12 14:17:04 PST 2004
Donn,
Nice job on the sharing wiki update.
A couple comments:
An Invite object just an API that allows creation, sending, of a
sharing invitation. Our implementation for 0.5 will use Mail as a
transport for these invites, just as we did in 0.4. Additionally we'll
add a way for the Mail to point back to the Sharing Status, so we can
update the status when a delivery error occurs. Sometimes these errors
happen immediately, but sometimes they happen after a successful
sending of the mail, e.g. an hour later the mail is bounced as
undeliverable. We'll reflect these errors back in the Sharing Status
for the affected sharees.
The bounced mail issue is harder than it sounds. There is no standard
convention for servers bouncing mail. While it is possible in the
majority of cases to determine if the incoming mail is a bounce from an
SMTP server some bounced mail replies may slip through. This is
basically a trial and error approach of looking at the responses
returned from the most popular SMTP servers (Sendmail, Cyrus, etc) and
then adding support from other servers over time. We currently do not
check for bounced mail. I would consider this feature post .5 as it is
not mission critical.
An Invite object just an API that allows creation, sending, of a
sharing invitation. Our implementation for 0.5 will use Mail as a
transport for these invites, just as we did in 0.4. Additionally we'll
add a way for the Mail to point back to the Sharing Status, so we can
update the status when a delivery error occurs. Sometimes these errors
happen immediately, but sometimes they happen after a successful
sending of the mail, e.g. an hour later the mail is bounced as
undeliverable. We'll reflect these errors back in the Sharing Status
for the affected sharees.
The .5 release would be a good time to solidify the generic API for
sharing transport . Mail as the first transport can then
implement this API. Although probably not the right approach for
Chandler an example pattern from Java would be to create an interface
i.e ISharingTransport and then utilizing a factory i.e.
SharingTransportFactory to return implementors of the interface.
Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
On Nov 11, 2004, at 9:32 AM, Donn Denman wrote:
> Thanks for the great feedback everyone. I have rewritten the wiki to
> incorporate your feedback. I got rid of Invitation status and added a
> section on the Chandler client side objects and their API:
>
> http://wiki.osafoundation.org/bin/view/Chandler/SharingStatusApi
>
> - Donn Denman
>
> On Nov 9, 2004, at 11:27 AM, Brian Kirsch wrote:
>
>> Hi Donn,
>> I have some feedback for the Invitation Status proposal.
>>
>> We can think of an Invitation as a special email, and track it from
>> the time it's requested, through sending, possible error states,
>> acceptance at the recipients end, and a confirmation reply.
>>
>> I would try and stay away from coupling sharing and email in anyway
>> and instead use either our much needed Notification Manager or the
>> Item Query proposal floating around as the means of tracking state.
>> Email should merely be a transport and a clean design pattern will
>> make it easy to drop in other transports (XMPP, SOAP) at a future
>> date.
>>
>> Sharing Status and Calendar Event Status can be built on top of
>> Invitation Status. For Sharing, the status starts out simply being
>> the Invitation Status, but once sharing commences the WebDAV server
>> becomes the communication conduit. As new "Sharees" are added,
>> additional Invitations are created and those Invitation Status
>> objects connected to the Sharing Status object. Calendar Event Status
>> looks like it could simply be a sequence of invitations sent to
>> various participants.
>>
>> Hum, although I am not fully informed on all the design requirements
>> this seems over complex to me. I read this paragraph a few times and
>> am still having a hard time picturing all the status mutations
>> described above. My hope is that there might be a more straight
>> forward way to design this relationship.
>>
>>
>> I guess my overall suggestion would be to provide a more detailed
>> description of the requirements coming from the design team and why
>> this is the correct solution. Some pseudo code snippets would be
>> extremely helpful as well.
>> I am worried that this solution will be hard for developers including
>> myself to grasp and work with.
>>
>>
>>
>>
>>
>>
>>
>> Brian Kirsch - Email Framework Engineer
>> Open Source Applications Foundation
>> 543 Howard St. 5th Floor
>> San Francisco, CA 94105
>> (415) 946-3056
>>
>> On Nov 9, 2004, at 10:11 AM, Katie Capps Parlante wrote:
>>
>>> Does "sharing status" need to be more than an enumeration? Should a
>>> "sharing status" object really be tracking email vs just storing the
>>> latest state?
>>>
>>> I think I don't know enough about the service that Brian is
>>> providing to understand the overall design for invitations, my
>>> comments might be more helpful if I understood the overall plan.
>>>
>>> Cheers,
>>> Katie
>>>
>>> Donn Denman wrote:
>>>
>>>> My intent was to describe the requirements that would drive a
>>>> particular set of schema changes like you outline below, to make
>>>> sure those requirements are being met appropriately. Hopefully the
>>>> kind of thing you show below will be the next step.
>>>> - Donn
>>>> On Nov 8, 2004, at 11:54 AM, Morgen Sagen wrote:
>>>>> Donn, does this page represent what you and I drew on the white
>>>>> board last week? It's a bit hard for me to follow from that text
>>>>> description what the kinds and relationships are. To help me
>>>>> understand, could you list out the new kinds and attributes? Here
>>>>> is how I interpret what you're saying:
>>>>>
>>>>> Kind ContentItem
>>>>> Attribute sharingStatus, type = SharingStatus (?) inverse
>>>>> attribute of "item"
>>>>> [Do "sharer" and "sharees" attributes go away?]
>>>>>
>>>>> Kind EmailAddress
>>>>>
>>>>> Kind InvitationStatus
>>>>> Attribute "person", type = EmailAddress
>>>>>
>>>>> Kind SharingStatus (subKind of InvitationStatus?)
>>>>> Attribute "sharees", type = InvitationStatus (?)
>>>>> Attribute "status", type = Enumeration (Not Sent, Sent,
>>>>> Accepted, Error, ...)
>>>>> Attribute "item", type = ContentItem (inverse attribute
>>>>> of "sharingStatus")
>>>>>
>>>>> Kind CalendarEventStatus (subKind of InvitationStatus?)
>>>>> ?
>>>>>
>>>>>
>>>>>
>>>>> On Nov 8, 2004, at 11:33 AM, Donn Denman wrote:
>>>>>
>>>>>> Katie, Morgen and Brian,
>>>>>>
>>>>>> Please take a minute to read what I've written about Invitation
>>>>>> Status and let me know what you think:
>>>>>>
>>>>>> http://wiki.osafoundation.org/bin/view/Chandler/InvitationStatus
>>>>>>
>>>>>> - Donn
>>>>>>
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>> From: Donn Denman <donn at osafoundation.org>
>>>>>>> Date: November 8, 2004 11:25:21 AM PST
>>>>>>> To: OSAF Development <Dev at osafoundation.org>
>>>>>>> Cc: Subject: [Dev] Content Model wiki updated
>>>>>>>
>>>>>>> I've updated the wiki page for Content Model development:
>>>>>>>
>>>>>>> http://wiki.osafoundation.org/bin/view/Chandler/
>>>>>>> ContentModelProject
>>>>>>>
>>>>>>> At the top of the page I added a task list for 0.5 that has
>>>>>>> links to proposal pages for the various tasks to be done in that
>>>>>>> timeframe.
>>>>>>>
>>>>>>> - Donn Denman
>>>>>>>
>>>>>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>>>>>
>>>>>>> Open Source Applications Foundation "Dev" mailing list
>>>>>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 7802 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20041112/5f31fb11/attachment.bin
More information about the Dev
mailing list