[dev] [cvs] commit: kronolith/lib api.php mnemo/lib api.php nag/lib api.php turba/lib api.php

[Karsten Fourmont]

Jan Schneider wrote:
> Dropping the array parameter for the export methods looks like BC break 
> to me.

Well theoretically: yes. Practically: no.
The array parameters were introduced by me for SyncML needs. They were 
always an ugly hack and never really worked. I doubt anyone besides my 
SyncML code ever used it.

After the iCalendar cleanup this hack is no longer necessary or useful, 
so I decided to remove it. If anybody relies one it: just let me know, 
and I'll to introduce some BC-keeping code into the api.php files.

With the new iCalendar there's just one bit of optional information you 
want to pass to the turba export: whether you want vcard2.1 or vcard3.0.

Currently a call of _turba_export($uid,'text/x-vcard') creates vcard3.0 
while _turba_export($uid, 'text/x-vcard;version=2.1') creates 2.1. 
Please note that the string 'text/x-vcard;version=2.1' is nonstandard. 
But it's only a parameter and doesn't appear in the output.

My question is: the way it's know vcard3.0 is the default. We can also 
do it the other way round making 2.1 the default and 3.0 only optional. 
Opinions?

For VEVENTs and VTODOs this is not an issue: text/calendar is the 
rfc2445 VCALENDAR 2.0 while text/x-vcalendar is VCALENDAR 1.0.



Cheers,
  Karsten