On Fri, 2003-09-12 at 01:32 -0400, JP Rosevear wrote: > So, using create/modify/remove object methods in the calendar (matching > the addressbook api) is starting to shape up nicely, however I > encountered one problem. Create has the nice feature of returning the > uid of the object created (addressbook does this because it can't > dictate to the ldap server the id I believe). This is nice since it > allows us to match the server ids (esp. in the groupwise case where we > can't set any old uid). > > Now, the problem I've encountered is that itip/imip needs to keep the > exact uid for 3rd party objects arriving via email. > hmm, right
> Aside from dropping this system entirely, I've thought about a couple of > things: > > 1. Add a receiveObject call to match the sendObject call - both will be > itip/imip specific (I think this still causes some work in the case of > groupwise since this part will force us to retain a mapping of 3rd party > uids to groupwise uids). > retain a mapping? Can't you create objects in the GW server with any UID? > 2. Allow modify to create objects as well (*ugly*), and these objects > will preserve all the attributes. > > 3. Some sort of parameter to create that forces it to use the existing > uid (only slightly less ugly than 2) > 1 seems the best to me, if it can easily be implemented for the GW connector. I like the receiveObject idea, since it makes clear the distinction, which might be even more important for future connectors. cheers _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
