Re: shared mailing groups

> > 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.

Do you mean the idea is that zOGI would return a Group as a transient 
entity?

> > 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.

I can see how the single transaction could eliminate duplicate emails.  I 
don't see how the MTA could expand a group name into a list of email 
addresses.  Maybe I'm misunderstanding what you mean by "expand".
 
> > 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).

I think I might have caught up with your thinking on this.  It occurred to 
me later that a Group could just be an email address (e.g. 
[email protected]).  Users would send an email to that 
address, and that address would be expanded into a list of recipients, and 
the email redirected to each member of the list. 

Following this idea then users can use whichever email client they want, 
whilst the server would still maintain the shared group.  The question is 
how to redirect email to that group address, and how to maintain the 
group.

One way of doing the expansion might be using sieve.  I can see that sieve 
can redirect email to at least one recipient. I will need to see if the 
sender remains unchanged in the redirect, and whether or not the 
redirection can be to multiple people.  If either of those don't work, 
then sieve is a non-starter.

That would mean OGO writing out sieve scripts, which may be completely 
inappropriate. I'm sure others have got better ideas about how this should 
be implemented.

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