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. 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). 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) Any other thoughts? -JP -- JP Rosevear <[EMAIL PROTECTED]> Ximian, Inc. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
