On Wed, 2002-03-13 at 06:58, JP Rosevear wrote: > On Mon, 2002-03-11 at 09:37, Russell Steinthal wrote: > > On 11 Mar 2002 09:27:25 EST, JP Rosevear wrote: > > > > >On Mon, 2002-03-11 at 05:56, Gene W. Marsh wrote: > > > > >> A second difficulty is in deciding what happens when a category name on > > >> the palm changes, is removed, or first appears. I think creating an > > >> interactive conduit would be nice. (That is what is done under Windows > > >> with Outlook.) While this is a neat idea, I have no idea if an > > >> interactive conduit is possible under gnome-pilot. I would suggest an > > >> intermediate step. Define the category mapping at configuration time. > > >> Also allow the user an option for how to deal with unmapped (either new > > >> or renamed) categories. If during a synch a category exists on the palm > > >> that is not already mapped, he may choose to create a mapping to an > > >> evolution category of the same name, creating it if it doesn't exist, > > >> and adding it to the master list, or ignore that cagtegory altogether. > > >> If a category is eliminated, just remove it from the mapping, but leave > > >> the name in evolution. (It may need it for historical records.) > > > > > >Renaming is really the big problem. You really don't want any > > >interaction on the conduit side. Your config option sounds > > >interesting. BTW, if you are going to hack this, it should be done > > >against the cvs mainline (what will be 1.2). > > > > It seems to me that the problem of renaming is only one way: Evo ---> > > Pilot, since one can always "define" a new Evolution category to > > correspond with any newly created Pilot category by simply adding the > > appropriate text string to the record. It seems to me that when an > > Evolution category is renamed, there are two possibilities: either the > > Pilot has a free category slot (probably true for most users) or it > > doesn't. If there's a free slot, we could simply fill it; if there > > isn't a free slot, the appropriate thing to do appears to be to put > > the record in either "Unfiled" or the user-specified default category. > > Its easy to limit the categories mapped to the palm from evo. The > problem is Pilot ---> Evo since when you rename the category, the id > associated is the same on the pilot but on evo there is no separate id > identifying the category, its only stored as a string. The real problem > is that the category is listed by name in each individual appointment > its used in, so a rename on the pilot involves finding all relevant > appointments and updating the category string.
True. But changes in the names of Palm categories are reflected in the database API, so you can know that the change has happened. > > > Interactively handling this seems fairly elegant from a user > > perspective, so I'm curious: why do you think we should avoid > > interactivity? Is it a technical limitation, experience, etc.? > > Its a couple of things, partially its a technical limitation, you don't > really want to be sending pings to the pilot all the time to keep the > device from timing out (although this is possible). In addition, you > don't want to create an interactive system which can a) require the user > to make an ever increasing number of decisions (ie for each record) and > b) required the user to be present for the several minutes a sync can > take. > > -JP > -- > -- > ======================================================================= > JP Rosevear [EMAIL PROTECTED] > Ximian Inc. http://www.ximian.com _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
