Re: shared mailing groups

> > > From the zOGI interface, it does appear 
> > > that Teams can contain Contacts (and not just Accounts), so I'm 
> > > assuming 
> > > that Teams would serve as a good basis for mailing groups. > 
> > If that is true it is an 'unintended feature'.  Teams should only
> > contain accounts.
> It could just be my misunderstanding of the sample code on the zOGI site. 
> I haven't tested it yet.  However, knowing that that is not how Teams 
> should work, I won't be using that as it may well become 'broken' in the 
> future.
> > >  My idea would 
> > > be to extract the Contact details from the Team, resolve unique email 
> > > addresses locally, populate the xml-rpc Mail object with the details, 
> > > and send the email through the OGO server via that old interface. 
> > Seems reasonable although the server might be able to help.  Look at the
> > code for the getNotifications API method.
> Sorry, but I don't understand how getNotifications might be useful.  It 
> only seems to relate to Appointments.

But the concept is that the server can 'unroll' some of the data for
you.  Rather than just returning the appointments that require
notification it creates a transient entity
<http://code.google.com/p/zogi/wiki/UnderstandingEntities> with the
information you are [obviously] going to need.

> > > I'd be grateful to hear what others think about this, and what you do 
> > > in regard to mailing groups.    I can see that what I'm trying to do 
> > > maybe falls between what zOGI is designed to do, and what the OGO web 
> > > interface is designed to do.
> > It seems reasonable, and not terribly hard, to create a new entity:
> > Group -that can contain contacts & enterprises.
> I haven't started to look at the Objective C code in OGO, but I'm relieved 
> to hear that adding Groups should not be too difficult.

The hardest part would be injecting it into the WebDAV space so that
something like Funambol could sync.  But beyond that I think a group's
representation in GroupDAV is just a simple vCard.

> > > A further problem I foresee is giving users access via Funambol -- 
> > > this  would also mean that they are using the local email client 
> > > of the phone, 
> > > and thus will lose the shared mailing groups (although it's great 
> > > that  Funambol can take care of the synchronization of contact
> > > data). 
> > Correct, on that level the groups need to be supported by the MTA.
But
> > that I think is really trivial (at least if your MTA is Postfix).
> > Delivery is probably best handled by the MTA anyway for a variety of
> > reasons.
> That the MTA should resolve the recipient identity sounds right, but maybe 
> it is expecting too much.  My installation of Postfix didn't seem to 
> reduce multiple emails to the same recipient to just one email.

It should flatten [I believe] if you specify the same destination more
than one *in the same transaction*.  If you perform two operations then
it is oblivious the two messages are related.   This is why it is good
to expand groups in the MTA and not externally.

> The issue I'm referring to with providing access via Funambol, is that the 
> shared mailing groups would be unavailable on a phone, unless the phone 
> email clients understand mailing groups and Funambol could sync such 
> things between the server and the phone.  I'd be very surprised to hear 
> that such synchronization was possible.

I think a group is a vCard just like a contact and an enterprise.  The
e-mail address in a group should/would indicate an address that is
expanded by the MTA (which will query to OGo backend).

-- 
OpenGroupware.org XML-RPC
[email protected]
http://mail.opengroupware.org/mailman/listinfo/xmlrpc