Re: GnomeCard conduit for gnome-pilot

> Martin Biely writes:
> > AFAIK every item in a vcalendar/vcard object has an id, it would be possible
> > to use a string of current IDs to see which are still there and which 
> > where deleted, this does howerver not change the modification problem. 
> There's only one problem with that, where do you store the string of
> current IDs? I don't think there's a place within the vcard/vcalendar
> file for that, so you're back to needing a separate file.

a litte miss understanding here. I was talking about a method in the IDL
that allows the "pilot" to ask which IDs do (still?) exist.
the IDs would be saved in the vcard/cal file with the item it belongs to.
the UID property should provide this functionality.

what would also be needed or would at least be helpfull is a second method
 to retrieve specific items based on their ID.

>  > >  > > ignored. I could do deletion by using a separate file, but that's
>  > >  > > ugly.
>  > 
>  > I don't know if this is more beautiful, its just an idea.
> I think it's the same one :) And it would work, it's just not nice,
> Unless you can think of how to store the string of current ids in the
> same file as vcards withouth breaking the vcard spec.
> Even better solution would be if there was ability to have a VCARD
> record still present in the file, but just marked deleted and ignored
> by gnomecard. Could be done with custom attribute, but I don't know
> if that would be breaking the spec.
> Modification could also be done pretty easily with custom attribute
> and proper support on gnomecard side. Or alternatively you could use
> REV attribute, but I'm not sure that's a good idea.

the REV attribute is optional so other implementations do not have to support 
it. I do not see why one should not use it. (but what do I have to say)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]