Re: [os-libsynthesis] More calendar tests problems
Hi Patrick, On Dec 2, 2009, at 16:08 , Patrick Ohly wrote: >> I doubt (but haven't tried to prove) that the MIME type in the SAN >> would really influence type negotiation, I'd assume it is used as a >> safer identifier for the store than the name is, but as long as you >> use a mime type that is valid for that datastore I'd expect it would >> trigger a sync in the same way as a manual start would. > > So you are proposing to always use "text/x-vcalendar" (or its binary > equivalent) even if we would prefer "text/calendar"? That might work, > except for those hypothetical handsets which *only* support > "text/calendar". Yes :-) >> Apart from that - are there any real world handsets doing iCalendar? > > SyncEvolution via obexd? ;-) Yes, and the iPhone (but that without SAN). But these will negotiate the type via devInf, no matter how they were alerted. >>> Did you see my proposal to change the distribution of the example >>> configs? Instead of including two monolithic examples which partly >>> overlap (profiles), I'd prefer to have several smaller files with atomic >>> units (one rule/profile/field list/etc per file). >> >> Yes, makes much sense. In fact, we are generating our own sample >> configs from a bunch of such fragments (PHP files) for years already. >> We have once thought about allowing includes through XML processing >> instructions in the config itself, but discarded the idea as it would >> introduce a heap of sideline problems like search paths, and probably >> that alone would not be sufficient to solve the real world >> modularisation required. > > Agreed. We'll have to solve the search path problems in SyncEvolution. > > So how do we proceed with this in the git repos? Do you think you can > set up something which follows your existing fragments or should I split > up the existing sample configs in our repo and you merge that back? The current libsynthesis samples are not generated from fragments, but manually derived from the iPhone configs at this time. So I'd prefer to merge back your proposal and possibly re-use that later for the iPhone and other libsynthesis based products. Feel free to structure it according to your needs. >> IMHO using some sort of external config preprocessing (be it PHP or M4 >> or whatever running at build time, or ad-hoc generation at runtime) is >> the better approach for anything beyond what can be done with the >> engine's config variables and the built-in "if/ifdef/ifndef" attribute >> system. > > The problem with that might be that the config has to be complete before > the engine even knows what peer it is talking to. For other cases > SyncEvolution already puts the desired settings into a generated XML > config. Maybe for the per-peer dependency cases we'd need to enhance the remoterules system. The entire design of the config is that once a server starts operating, the config remains constant (strictly read-only object tree, possibly shared between multiple sessions in multiple threads). This was for efficiency and footprint (back in 2001) to avoid re-reading and re-resolving all config and scripts for every sync. Best Regards, Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] More calendar tests problems
On Wed, 2009-12-02 at 14:44 +, Lukas Zeller wrote: > On Dec 2, 2009, at 13:21 , Patrick Ohly wrote: > > >> With the large majority of devices, legacy mode is not needed. Unlike > >> servers, which often have very poor devInf (because very few clients > >> actually check it at all), most clients have proper devInf. So > >> automatic type negotiation should work (I'm not aware of a single > >> device which did not work). > > > > The problem in this case is that in order to start the automatic type > > negotiation, the right type must already be known when generating the > > SAN message. Apparently the Nokia phone uses the MIME type in the SAN > > instead of the datastore name to determine whether it supports it. > > I doubt (but haven't tried to prove) that the MIME type in the SAN > would really influence type negotiation, I'd assume it is used as a > safer identifier for the store than the name is, but as long as you > use a mime type that is valid for that datastore I'd expect it would > trigger a sync in the same way as a manual start would. So you are proposing to always use "text/x-vcalendar" (or its binary equivalent) even if we would prefer "text/calendar"? That might work, except for those hypothetical handsets which *only* support "text/calendar". > Apart from that - are there any real world handsets doing iCalendar? SyncEvolution via obexd? ;-) > > Did you see my proposal to change the distribution of the example > > configs? Instead of including two monolithic examples which partly > > overlap (profiles), I'd prefer to have several smaller files with atomic > > units (one rule/profile/field list/etc per file). > > Yes, makes much sense. In fact, we are generating our own sample > configs from a bunch of such fragments (PHP files) for years already. > We have once thought about allowing includes through XML processing > instructions in the config itself, but discarded the idea as it would > introduce a heap of sideline problems like search paths, and probably > that alone would not be sufficient to solve the real world > modularisation required. Agreed. We'll have to solve the search path problems in SyncEvolution. So how do we proceed with this in the git repos? Do you think you can set up something which follows your existing fragments or should I split up the existing sample configs in our repo and you merge that back? > IMHO using some sort of external config preprocessing (be it PHP or M4 > or whatever running at build time, or ad-hoc generation at runtime) is > the better approach for anything beyond what can be done with the > engine's config variables and the built-in "if/ifdef/ifndef" attribute > system. The problem with that might be that the config has to be complete before the engine even knows what peer it is talking to. For other cases SyncEvolution already puts the desired settings into a generated XML config. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] Any observations of mobical.net having problems with client ?
Hi Patrick, Thanks for the feedback! We haven't heard back from that customer since, which usually means the problem has gone away (for whatever reason). I'm inclined to put this into the "random failures" (at mobical) department - it might well be that they had a temporary problem with adding records on the database layer, independently of vs. . Best Regards, Lukas On Nov 30, 2009, at 14:11 , Patrick Ohly wrote: > On Tue, 2009-11-17 at 19:11 +, Lukas Zeller wrote: >> I have a customer report indicating that the change made with >> c3ad24c31d (engine: statistics workaround for servers not sending >> status 201 for completed adds) sometimes confuses mobical.net and >> causes it to return status 400 for attempts to add items to the >> server. Not always, but sometimes. >> >> So far I was not aware of from client being a potential issue >> with mobical - so my question: did anybody experience spurious status >> 400 rejects while testing with mobical? I could not reproduce the case >> so far (havent tried too hard, either). > > We have tried with both "Add" and "Replace" for new items and have not > been able to reproduce such spurious rejects. > > We had some nightly test failures with Mobical.com in > "one-way-from-client" mode (server doesn't handle its own anchors > correctly, need "lenient" mode) and random failures (server returns > plain text instead of (WB)XML). But this is independent of the Google > statistics workaround. > > For details, see: http://bugzilla.moblin.org/show_bug.cgi?id=8121 > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] More calendar tests problems
Hi Patrick, On Dec 2, 2009, at 13:21 , Patrick Ohly wrote: >> With the large majority of devices, legacy mode is not needed. Unlike >> servers, which often have very poor devInf (because very few clients >> actually check it at all), most clients have proper devInf. So >> automatic type negotiation should work (I'm not aware of a single >> device which did not work). > > The problem in this case is that in order to start the automatic type > negotiation, the right type must already be known when generating the > SAN message. Apparently the Nokia phone uses the MIME type in the SAN > instead of the datastore name to determine whether it supports it. I doubt (but haven't tried to prove) that the MIME type in the SAN would really influence type negotiation, I'd assume it is used as a safer identifier for the store than the name is, but as long as you use a mime type that is valid for that datastore I'd expect it would trigger a sync in the same way as a manual start would. Apart from that - are there any real world handsets doing iCalendar? > This looks like something that we need to handle in SyncEvolution's > "database" of know devices or known device families. > >>> 2. Shall we (SyncEvolution) merge the remote rule configurations for >>> various phones already done by synthesis, so that we can benefit >>> immediately from synthesis excellent work. >> >> I'd recommend so. However, the rules that we have are mainly for >> ancient handsets. Most devices released in the past 3-4 years didn't >> need special rules any more. So that part of the config has become >> pretty static. >> >> However, please note fe11bb62b5 (server config: updated for 3.4.0.0 >> engine, fixed some bugs) I just posted - because of a change in the >> engine's default behaviour when interpreting text with no character >> set specified (in vCard 2.1/vCalendar 1.0 that is), some of these >> ancient remote rules need an update. > > Did you see my proposal to change the distribution of the example > configs? Instead of including two monolithic examples which partly > overlap (profiles), I'd prefer to have several smaller files with atomic > units (one rule/profile/field list/etc per file). Yes, makes much sense. In fact, we are generating our own sample configs from a bunch of such fragments (PHP files) for years already. We have once thought about allowing includes through XML processing instructions in the config itself, but discarded the idea as it would introduce a heap of sideline problems like search paths, and probably that alone would not be sufficient to solve the real world modularisation required. IMHO using some sort of external config preprocessing (be it PHP or M4 or whatever running at build time, or ad-hoc generation at runtime) is the better approach for anything beyond what can be done with the engine's config variables and the built-in "if/ifdef/ifndef" attribute system. Best Regards, Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] More calendar tests problems
On Wed, 2009-12-02 at 10:07 +, Lukas Zeller wrote: > On Dec 2, 2009, at 8:50 , Chen Congwu wrote: > > 1. Shall I use legacy mode? Since 7210c only supports vcalendar 1.0 (It does > > not accept ical content type via SAN and it sends messages in vcal1.0 > > format, so I assume this.) I just skimmed the sample configuraiton in > > syncserver_sample.xml and found some remote rule configuraitons for various > > phones, but did not see explict use of legacy mode. Have I made something > > wrong? > > The approach with our server is as follows: as little device specific > behaviour as possible. So unless we found that a device does not work, > there is no remoterule. > > With the large majority of devices, legacy mode is not needed. Unlike > servers, which often have very poor devInf (because very few clients > actually check it at all), most clients have proper devInf. So > automatic type negotiation should work (I'm not aware of a single > device which did not work). The problem in this case is that in order to start the automatic type negotiation, the right type must already be known when generating the SAN message. Apparently the Nokia phone uses the MIME type in the SAN instead of the datastore name to determine whether it supports it. This looks like something that we need to handle in SyncEvolution's "database" of know devices or known device families. > > 2. Shall we (SyncEvolution) merge the remote rule configurations for > > various phones already done by synthesis, so that we can benefit > > immediately from synthesis excellent work. > > I'd recommend so. However, the rules that we have are mainly for > ancient handsets. Most devices released in the past 3-4 years didn't > need special rules any more. So that part of the config has become > pretty static. > > However, please note fe11bb62b5 (server config: updated for 3.4.0.0 > engine, fixed some bugs) I just posted - because of a change in the > engine's default behaviour when interpreting text with no character > set specified (in vCard 2.1/vCalendar 1.0 that is), some of these > ancient remote rules need an update. Did you see my proposal to change the distribution of the example configs? Instead of including two monolithic examples which partly overlap (profiles), I'd prefer to have several smaller files with atomic units (one rule/profile/field list/etc per file). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] More calendar tests problems
Hi Congwu, On Dec 2, 2009, at 8:50 , Chen Congwu wrote: > Hi, I am encountering several questions syncing calendar with Nokia 7210c, > please be patient,;-) :-) > 1. Shall I use legacy mode? Since 7210c only supports vcalendar 1.0 (It does > not accept ical content type via SAN and it sends messages in vcal1.0 > format, so I assume this.) I just skimmed the sample configuraiton in > syncserver_sample.xml and found some remote rule configuraitons for various > phones, but did not see explict use of legacy mode. Have I made something > wrong? The approach with our server is as follows: as little device specific behaviour as possible. So unless we found that a device does not work, there is no remoterule. With the large majority of devices, legacy mode is not needed. Unlike servers, which often have very poor devInf (because very few clients actually check it at all), most clients have proper devInf. So automatic type negotiation should work (I'm not aware of a single device which did not work). > 2. Shall we (SyncEvolution) merge the remote rule configurations for > various phones already done by synthesis, so that we can benefit > immediately from synthesis excellent work. I'd recommend so. However, the rules that we have are mainly for ancient handsets. Most devices released in the past 3-4 years didn't need special rules any more. So that part of the config has become pretty static. However, please note fe11bb62b5 (server config: updated for 3.4.0.0 engine, fixed some bugs) I just posted - because of a change in the engine's default behaviour when interpreting text with no character set specified (in vCard 2.1/vCalendar 1.0 that is), some of these ancient remote rules need an update. > And of course we will > contribute back our new findings. So we need to setup a similar syncing > approach for configuration files for server case just like what we are > doing for client configurations? Probably yes. The remote rule part is largely independent of the rest of the config, so that should be easy to update with new entries on both sides. > To Patrick, do we need to seperate the server and client configurations just > like synthesis or stick to the combined approach we used at the moment? > > 3. TZ property is only declared in VCalendar profile, while the particular > phone sends it within vEvent subprofile, so I added the following to our > configuration: > field="ISEVENT" value="1"> > > + suppressempty="yes"> > + > + > > Yes, it is non-standard compliant. So can I have a specific profile for this > particular phone? You can add a "rule" attribute to a property to enable it only when a certain remote rule is active. > 4. STATUS property maybe used directly instead of as a parameter for ATTANDEE > property inside vEvent profile (This is vcal1.0 explictly states). So I will > add this declarion in vEvent subprofile. At this moment it parsed correctly, > however when it starts to store to datastore (during beforewrotescript), it > still losts the STATUS, I am checking on this at the moment. > > 5. For clients which do not support UTC time (common case for phones?), Common for very old ones, and forced via remote rules for phones known having broken UTC/localtime conversion. Phones released in the last 3-4 years usually have working UTC conversion. Some may lack the flag in the devInf, these can be fixed by a remote rule forcing the engine to use UTC even if the flag is missing. > [...] we will > send the time as localtime (not floating time? Does it mean vcal1.0 does not > have such a concept?). vCal 1.0 cannot really differentiate local and floating time. Of course, when there is a TZ/DAYLIGHT, the timestamps are not floating, but in that time zone. However a missing TZ/DAYLIGHT in many cases also means "local time". This is all a bit fuzzy with vCalendar 1.0. > However we did not sent the TZ field to client, how can > the client correctly interprect this? It can't, but clients not capable of UTC usually can't do anything more than just display the time as-is. So sending it in "usertimezone" is the best match we can get. (see config reference doc about "usertimezone", by default this is the server's local tz, but can vary on a per-user level, e.g. by loading a user preference in one of the ). > see example: > This is what local datastore is: > BEGIN:VCALENDAR > CALSCALE:GREGORIAN > PRODID:-//Ximian//NONSGML Evolution Calendar//EN > VERSION:2.0 > BEGIN:VEVENT > SUMMARY:phone meeting > DTEND:20060406T163000Z > DTSTART:20060406T16Z > DTSTAMP:20060406T211449Z > LOCATION:my office > DESCRIPTION:let's talk<> > UID:20091202t070241z-12684-1000-...@shlabwcchen35 > CREATED:20091202T070241Z > LAST-MODIFIED:20091202T070241Z > END:VEVENT > END:VCALENDAR > > This is what we sent: > BEGIN:VCALENDAR > VERSION:1.0 > BEGIN:VEVENT > SUMMARY:phone meeting > DESCRIPTION:let's talk<> > LOCATION:my office > DTSTART:20060407T00 > D
Re: [os-libsynthesis] More calendar tests problems
On Wed, 2009-12-02 at 07:50 +, Chen Congwu wrote: > 2. Shall we (SyncEvolution) merge the remote rule configurations for > various phones already done by synthesis, so that we can benefit > immediately from synthesis excellent work. And of course we will > contribute back our new findings. So we need to setup a similar syncing > approach for configuration files for server case just like what we are > doing for client configurations? Absolutely. There's an open issue (#7712) and in one of my recent mails to this list (Subject: "merging branches + XML config tracking") I brought up the same question. > To Patrick, do we need to seperate the server and client configurations just > like synthesis or stick to the combined approach we used at the moment? See that email - I would prefer separate files, plus a mechanism in SyncEvolution to gather them into one XML config at runtime. > 5. For clients which do not support UTC time (common case for phones?), we > will > send the time as localtime (not floating time? Does it mean vcal1.0 does not > have such a concept?). However we did not sent the TZ field to client, how can > the client correctly interprect this? [...] > This is what we sent: > BEGIN:VCALENDAR > VERSION:1.0 > BEGIN:VEVENT > SUMMARY:phone meeting > DESCRIPTION:let's talk<> > LOCATION:my office > DTSTART:20060407T00 > DTEND:20060407T003000 > END:VEVENT > END:VCALENDAR The server needs to know (or guess) what the local time zone of the phone is and convert all time stamps into that zone. Yes, this is error prone. Yes, it can break for recurring events in "foreign" time zones. Stupid phones. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] System Timezone detection is wrong?
Patrick wrote: >On Wed, 2009-12-02 at 02:49 +, Chen, Congwu wrote: >> Hello, >> On linux (platform_adapters/linux/platform_timezones.cpp), >> the implementation of getSystemTimeZoneContext seems have >> problems: it use tzset() and later check tzname[0], tzname[1] >> to match against a built-in known timezone table (sysync/tz_table.h). > >There's an open issue about this: >http://bugzilla.moblin.org/show_bug.cgi?id=3477 > >The solution proposed [...] > >Is the local timezone perhaps configurable? Then such highly platform >and client specific code could reside in the client, with the some less >elaborate fallback in the library itself. I think there is a configuration variable: "systemtimezone". We may detect the local timezone in our application and set it in the configuration. Best Regards, Congwu ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] System Timezone detection is wrong?
On Wed, 2009-12-02 at 02:49 +, Chen, Congwu wrote: > Hello, > On linux (platform_adapters/linux/platform_timezones.cpp), > the implementation of getSystemTimeZoneContext seems have > problems: it use tzset() and later check tzname[0], tzname[1] > to match against a built-in known timezone table (sysync/tz_table.h). There's an open issue about this: http://bugzilla.moblin.org/show_bug.cgi?id=3477 The solution proposed there uses other sources of timezone, or rather, location information which are available on a Linux system. It would access those at the expense of adding further system dependencies to libsynthesis (libjana). Is the local timezone perhaps configurable? Then such highly platform and client specific code could reside in the client, with the some less elaborate fallback in the library itself. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] System Timezone detection is wrong?
Hello Chen,
as we've seen already, the timezone detection is a very heuristic problem.
It makes it extremely complicated and unreliable,
if a system is not providing correct, incomplete
or even wrong information. If you only get the
names, you need an internal table to get the
start and end time of DST anyway.
Unfortunately not all Linux/Unix systems provide
much more than tzset(), so this is also not a
general solution using a daylight variable.
We could think about a compile switch for linux
systems which can provide more information. Our
MacOSX/iPhoneOS implementations are basing also
on other functions than tzset() for time zone
detection.
Regards,
Beat
Hello,
On linux (platform_adapters/linux/platform_timezones.cpp),
the implementation of getSystemTimeZoneContext seems have
problems: it use tzset() and later check tzname[0], tzname[1]
to match against a built-in known timezone table (sysync/tz_table.h).
I found the tzname fields set by tzset() is incorrect or at least ambiguous
on ubuntu karmic, fedora 11.
In my case, my system timezone is Asia/Shanghai
(UTC+8), but synthesis engine will
detect is as UTC-6.
My conclusion is we cannot use tzname fields to
detect the timezone, maybe we can
try use timezone and daylight variable instead?
--
See below tests:
The samle code is as below:
tzset()
printf ("tzname[0] %s\n", tzname[0]);
printf ("tzname[1] %s\n", tzname[1]);
---
Here are the output on Ubuntu karmic:
TZ=':Asia/Shanghai' ./test
tzname 0 CST
tzname 1 CDT
TZ=':America/Chicago' ./test
tzname 0 CST
tzname 1 CDT
TZ=':Asia/Tokyo' ./test
tzname 0 JST
tzname 1 JDT
Best Regards,
Congwu
___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
--
---
Beat FORSTER
Dipl. El. Ing. ETH
Dipl. NDS ETHZ in Betriebswissenschaften
Managing Partner
beat.fors...@synthesis.ch
Synthesis AG SyncML Server & Client Solutions
Badenerstrasse 18, CH-8004 Zürich, Switzerland
Tel (direct): +41 44 440 66 02
Fax:+41 44 440 66 04
email: i...@synthesis.ch
web: http://www.synthesis.ch
---
___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
[os-libsynthesis] More calendar tests problems
Hi, I am encountering several questions syncing calendar with Nokia 7210c, please be patient,;-) 1. Shall I use legacy mode? Since 7210c only supports vcalendar 1.0 (It does not accept ical content type via SAN and it sends messages in vcal1.0 format, so I assume this.) I just skimmed the sample configuraiton in syncserver_sample.xml and found some remote rule configuraitons for various phones, but did not see explict use of legacy mode. Have I made something wrong? 2. Shall we (SyncEvolution) merge the remote rule configurations for various phones already done by synthesis, so that we can benefit immediately from synthesis excellent work. And of course we will contribute back our new findings. So we need to setup a similar syncing approach for configuration files for server case just like what we are doing for client configurations? To Patrick, do we need to seperate the server and client configurations just like synthesis or stick to the combined approach we used at the moment? 3. TZ property is only declared in VCalendar profile, while the particular phone sends it within vEvent subprofile, so I added the following to our configuration: + + + Yes, it is non-standard compliant. So can I have a specific profile for this particular phone? 4. STATUS property maybe used directly instead of as a parameter for ATTANDEE property inside vEvent profile (This is vcal1.0 explictly states). So I will add this declarion in vEvent subprofile. At this moment it parsed correctly, however when it starts to store to datastore (during beforewrotescript), it still losts the STATUS, I am checking on this at the moment. 5. For clients which do not support UTC time (common case for phones?), we will send the time as localtime (not floating time? Does it mean vcal1.0 does not have such a concept?). However we did not sent the TZ field to client, how can the client correctly interprect this? see example: This is what local datastore is: BEGIN:VCALENDAR CALSCALE:GREGORIAN PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 BEGIN:VEVENT SUMMARY:phone meeting DTEND:20060406T163000Z DTSTART:20060406T16Z DTSTAMP:20060406T211449Z LOCATION:my office DESCRIPTION:let's talk<> UID:20091202t070241z-12684-1000-...@shlabwcchen35 CREATED:20091202T070241Z LAST-MODIFIED:20091202T070241Z END:VEVENT END:VCALENDAR This is what we sent: BEGIN:VCALENDAR VERSION:1.0 BEGIN:VEVENT SUMMARY:phone meeting DESCRIPTION:let's talk<> LOCATION:my office DTSTART:20060407T00 DTEND:20060407T003000 END:VEVENT END:VCALENDAR -- Regards, Chen Congwu Moblin China Development ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
