[SyncEvolution] Help! how do I stop desktop notifications!
by Brian
Hi,
Using Fedora16/SyncEvolution 1.2-2.
I've googled, I've searched, I've grepped(-r) and I cannot find any way to turn
off these infernal notifications!!! I still want the sync to happen regularly
(to funambol), I just don't want to be interrupted every time the sync starts
and completes!
Is there anyway to end my torment?!?
Thanks!
Brian
7 years, 8 months
[SyncEvolution] bridgie syncml server and caldav/card dav server
by Robert Schetterer
Hi, is there a chance to use syncevolution
as a bridge between a syncml server and a caldav/carddav server and vice
versa
i.e horde or funambol server syncml and DAViCal etc
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
7 years, 8 months
[SyncEvolution] 409 "item merged" in client
by Patrick Ohly
Hello!
I've started to test SyncEvolution client <-> SyncEvolution server
automatically. The server is currently using the plain file backend and
thus cannot detect add<->add UID conflicts.
In the test of that aspect I noticed the following problem:
* client and server both have a new item with UID=foo
* client sends an Add UID=foo to the server, which accepts the new
item, leading to a duplication on the server
* in the same session, the server sends his version of the UID=foo
item
* the client's backend detects the duplicate and returns 409 to
the engine
Here's the detailed log:
http://syncev.meego.com/2011-12-14-12-24_testing_syncevohttp/testing-amd6...
* [2011-12-14 12:48:53.896] InsertItemAsKey res=409
* [2011-12-14 12:48:53.897] cannot create record in database
(sta=409)
* [2011-12-14 12:48:53.898] Database Error --> SyncML status 409
* [2011-12-14 12:48:53.899] - Operation add failed with SyncML
status=409
–[2011-12-14 12:48:53.900] End of 'Process_Item' [->top] [->enclosing]
* [2011-12-14 12:48:53.901] processSyncOpItem: Error while processing
item, status=409
* [2011-12-14 12:48:53.902] Irregularity in execution of item,
status=409
–
[2011-12-14 12:48:53.903] 'issue' - issuing command,
Cmd=Status [--][++] [->end] [->enclosing]
* [2011-12-14 12:48:53.903] Command 'Status': is 1-th counted cmd,
cmdsize(+tags needed to end msg)=38, available=149687
(maxfree=260907, freeaftersend=260869,
notUsableBufferBytes()=111220)
* [2011-12-14 12:48:53.904] WARNING: Non-OK Status 409 returned to
remote!
>From there on it all goes south ;-)
The next sync in my testing is an intentional slow sync. The server
still has the two items with the same UID, the client adds one, then
rejects the second => slow sync fails, test aborts.
Lukas, can you remind me how this was meant to work?
--
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.
7 years, 10 months
[SyncEvolution] Syncevolution build system conversion
by Krzesimir Nowak
Hi.
My name is Krzesimir Nowak. I work for Openismus GmbH who asked me to
try to convert Syncevolution's build system to a (simpler) non-recursive
Automake build. I now have something that works, with no obvious
regressions.
I've been working in a remote branch (I branched from Chris Kuehl's
dbus-server-reorganization because that already has some improvements
and it looks like it will get into master first).
https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c...
but I have also attached it as one patch, which might be easier to
review.
This should be simpler and more robust (for instance, against weird
linker problems), with less duplication, and it allows faster builds via
make -j.
It also removes the pre/post configure system and the *-gen.am system
which can be unfamiliar to regular users of autotools.
Patrick's minimum requirement was to still have the version number
autogenerated from the git version, and I have managed to keep that.
Patrick also preferred not having to list all the templates and config
files, but I have only partly achieved that.
I think it would be wise to make further step-by-step improvements once
this first step is in master. For instance, see:
https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c...
Regards,
Krzesimir
7 years, 11 months
Re: [SyncEvolution] syncevo-dbus-server + forking processes
by Patrick Ohly
On Mi, 2011-12-14 at 15:44 +0100, Chris Kühl wrote:
> >> Ok, I'm looking into this. The original plan was that Step 1 was a
> >> dependency of Step 2 but I've been reconsidering my approach. I'll
> >> look into what you're asking and get back to you soon.
> >
> > I can also do that part myself, if you give me some pointers to
> relevant
> > technical documentation. I was looking for information on
> bootstrapping
> > a D-Bus connection over a pair of connected file descriptors,
> without
> > much luck.
> >
>
> Well, in GIO GDBus you can create a connection using a GIOStream using
> g_dbus_connection_new_sync(). Not sure if that would really work the
> way you want, though.
Looks promising.
How about the same thing for libdbus?
> I've no problem doing this, though.
I don't care either way, as long as we can get it done soon, like this
week ;-)
--
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.
7 years, 12 months
[SyncEvolution] Nokia N9 Woes
by justus-bulk＠piater.name
Hi -
I am having trouble getting my N9 to sync with my Linux box, probably at
least partially due to my limited understanding of how the N9 is set up
internally.
I first tried syncml-ds-tool, which allows me to shuffle data back and
forth via USB/OBEX or Bluetooth/OBEX, but no real record-wise sync.
I then tried opensync over bluetooth, but am having persistent bluetooth
problems (I cannot browes files on the N9 over obexftp using any tool,
for example), so I gave up on this front for now. Any advice would be
appreciated.
I have not tried opensync over USB. Perhaps this would be a promising
route. Any advice would be appreciated.
I tried syncevolution over bluetooth, but persistently got transport
errors (presumably for the same reasons as the opensync troubles), and
gave up for now.
I then installed
http://people.debian.org/~ovek/harmattan/syncevolution_1.2.1-1_armel.deb
on the N9, and set up syncevolution with syncevo-http-server on the
laptop. This produced first success: I can sync contacts and multiple
caledars over an IP connection. However:
- There appears to be no way to sync memos and todos using this setup.
Both are apparently stored inside /home/user/.calendar/db on the N9,
along with the calendar data, but from inspecting the source code of
this Harmattan syncevolution build it appears that these cannot
currently be sync'ed because this has simply not yet been implemented.
- Sync is extremely slow. My 1000+ contacts take more than 10 minutes
to sync, even if there are no changes on either side. (On my Palm
this takes about 1 second, even if there are records to be sync'ed.)
The N9 syncevolution client fully charges the CPU for much of this
time.
- I had trouble getting all of my data onto the N9 because of timeouts
and other issues. I was completely unable to transfer my 13 years
worth of appointments ("D-Bus peer has disconnected" after many
minutes and transferring 212/5955 appointments), and had to resort to
moving the entire past into an unsync'ed calendar on the laptop.
Thus, I am interested in trying out the N9's built-in sync facilities
instead of the custom Harmattan syncevolution client, but I have found
no way to do this:
- Is there a way to use syncevolution on the laptop to initiate a sync
with the N9 using OBEX over USB?
- I have not found a way initiate on the N9 a sync with the laptop
(short of installing Funambol or something, which I'd prefer to
avoid).
- The latter should work via bluetooth, but I have not found a way to
get my laptop to advertise OPP, so the N9 does not offer the (paired)
laptop as a sync peer. Any hints?
Given this experience, I am puzzled by Fredrik's announcement of success:
On Tue, 2011-10-25 at 12:59 +0200, Frederik Elwert wrote:
> I recently got a Nokia N9, and I am now experimenting with
> SyncEvolution to get my Desktop and the N9 in sync.
>
> It started fairly promising: I could add the N9 with the Nokia
> template in sync-ui. In general, sync works quite fine. So the N9
> seems to be capable enough by default to get this kind of things
> right.
Perhaps I am missing something obvious? Any suggestions are welcome.
Justus
8 years
[SyncEvolution] Online contacts in Harmattan
by Ove Kåven
While I'm at it, someone told me that on the N950 (Harmattan), when he
was logged onto Facebook, SyncEvolution would try to include his entire
Facebook friend list in the sync, which is unfortunate.
Before I spend too much time looking into it myself (I don't have much
of it, after all), do you know an obvious way in QtContacts to suppress
such online contacts, so that only contacts that are actually stored in
the device's own database would be synced?
8 years
[SyncEvolution] Memotoo tasks: PERCENT-COMPLETE:100
by Patrick Ohly
Hello Thomas!
I ran a new full test over the weekend and found one issue:
-------------------------------------------------------------------------------
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
SUMMARY:test task with plenty of fi SUMMARY:test task with plenty of fi
elds elds
CATEGORIES:Business,Waiting CATEGORIES:Business,Waiting
COMPLETED:20090401T050000 COMPLETED:20090401T050000
DESCRIPTION:This is a test task in DESCRIPTION:This is a test task in
time zone New York\, to be started time zone New York\, to be started
May 1st 2009 (not supported by Memo May 1st 2009 (not supported by Memo
too)\, due Mai 2st 2009.\n\nIt uses too)\, due Mai 2st 2009.\n\nIt uses
non-standard status values. non-standard status values.
DUE:20090502T190000 DUE:20090502T190000
> PERCENT-COMPLETE:100
STATUS:COMPLETED STATUS:COMPLETED
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
-------------------------------------------------------------------------------
It seems that Memotoo adds a PERCENT-COMPLETE:100. The original data has
no PERCENT-COMPLETE when testing with Memotoo (see below).
The standard doesn't say anything about a default value for
PERCENT-COMPLETE; my own intuition suggests that "nothing said = nothing
done = PERCENT-COMPLETE:0" would be a better choice than 100% done.
Has Memotoo started to support PERCENT-COMPLETE? What about DTSTART?
The Memotoo version of the task test case was modified a while ago to
not have PERCENT-COMPLETE and DTSTART:
commit 358e8fc03b60ad6e34fb1815bf20694745ce8571
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Aug 10 16:02:30 2011 +0200
Memotoo testing: updated eds_task test case for Memotoo
Time stamp for COMPLETED is converted to local time by Memotoo.
DTSTART and PERCENT-COMPLETE are lost.
--
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.
8 years
[SyncEvolution] Session dbus api and documentation
by Chris Kühl
Hi Patrick,
When looking into why the Session has a GetConfigs dbus method, I
noticed that there are several dbus methods which are not documented
in syncevo-session-full.xml. This includes Attach which is actually
mention but not properly documented in that file.
Is this just a case of the docs being out of sync or are some of these
methods not intended to be in the session interface?
Cheers,
Chris
8 years, 1 month
[SyncEvolution] ActiveSync time zones
by Patrick Ohly
Hello,
I started to test against Exchange 2010 as provided by 123together.com.
I'm seeing an issue that I hadn't encountered in our private
installation of Exchange 2010: events without recurrence are converted
to US Eastern time, even if the event that was sent to the server had a
different time zone or used UTC.
For normal events, at least the times are converted correctly:
DTEND:20060406T193000Z | DTEND;TZID="(UTC-05:00) Eastern Tim
DTSTART:20060406T190000Z | e (US & C":20060406T153000
> DTSTART;TZID="(UTC-05:00) Eastern T
> ime (US & C":20060406T150000
So no real harm is done, it merely breaks the automatic testing.
But all-day events get the same treatment and there things go wrong:
SUMMARY:two day event SUMMARY:two day event
DTEND;VALUE=DATE:20060408 | DTEND;VALUE=DATE:20060407
DTSTART;VALUE=DATE:20060406 | DTSTART;VALUE=DATE:20060405
This happens because activesyncd first converts to the time according to
the provided timezone before truncating the time part. In this case that
shifts the event to different days.
Now it becomes unfair and a bit puzzling...
The data that is sent to the server has start/end time aligned to
midnight and uses a time zone that is equivalent to UTC (no bias set).
This is displayed okay by the server.
After creating an all-day event on 20060406 via the web interface (time
zone setting: UTC), it is send to the client like this:
<ApplicationData>
<TimeZone xmlns="Calendar:">AAAAACgAVQBUAEMAKQAgAEMAbwBvAHIAZABpAG4AYQB0AGUAZAAgAFUAbgBpAHYAZQByAHMAYQBsACAAVABpAG0AZQAAAAAAAAAAAAAAAAAAAAAAAAAAACgAVQBUAEMAKQAgAEMAbwBvAHIAZABpAG4AYQB0AGUAZAAgAFUAbgBpAHYAZQByAHMAYQBsACAAVABpAG0AZQAAAAAAAAAAAAAAAAAAAAAAAAAAAA==</TimeZone>
<DTStamp xmlns="Calendar:">20111207T102434Z</DTStamp>
<StartTime xmlns="Calendar:">20060406T000000Z</StartTime>
<Subject xmlns="Calendar:">all day event 123</Subject>
<UID xmlns="Calendar:">040000008200E00074C5B7101A82E0080000000080D6FE69CAB4CC01000000000000000010000000315841722E672440B2CF3933145398E3</UID>
<Organizer_Name xmlns="Calendar:">pohly-activesync</Organizer_Name>
<Organizer_Email xmlns="Calendar:">pohly-activesync(a)syncevolution.org</Organizer_Email>
<Location xmlns="Calendar:"/>
<EndTime xmlns="Calendar:">20060407T000000Z</EndTime>
<Body xmlns="AirSyncBase:">
<Type>1</Type>
<EstimatedDataSize>2</EstimatedDataSize>
<Data></Data>
</Body>
<Sensitivity xmlns="Calendar:">0</Sensitivity>
<BusyStatus xmlns="Calendar:">2</BusyStatus>
<AllDayEvent xmlns="Calendar:">1</AllDayEvent>
<MeetingStatus xmlns="Calendar:">0</MeetingStatus>
<NativeBodyType xmlns="AirSyncBase:">3</NativeBodyType>
</ApplicationData>
The AAAA.. time zone has zero bias and thus everything works.
(process:4844:0xbbbe9c0): libeas-DEBUG:process timezone AAAAACgAVQBUAEMAKQAgAEMAbwBvAHIAZABpAG4AYQB0AGUAZAAgAFUAbgBpAHYAZQByAHMAYQBsACAAVABpAG0AZQAAAAAAAAAAAAAAAAAAAAAAAAAAACgAVQBUAEMAKQAgAEMAbwBvAHIAZABpAG4AYQB0AGUAZAAgAFUAbgBpAHYAZQByAHMAYQBsACAAVABpAG0AZQAAAAAAAAAAAAAAAAAAAAAAAAAAAA== => bias 0, standard bias 0, daylight bias 0, standard '(UTC) Coordinated Universal Time', daylight '(UTC) Coordinated Universal Time'
Here's the unfair part: sending that same data back still has the same
problem. It shows okay, but gets converted when retrieving.
Why on earth is an event created via the web treated differently than an
event created via ActiveSync, when sending the same data from the client
to the server as the server sends to the client?
Here's the data that gets sent:
<ApplicationData>
<calendar:TimeZone>AAAAACgAVQBUAEMAKQAgAEMAbwBvAHIAZABpAG4AYQB0AGUAZAAgAFUAbgBpAHYAZQByAHMAYQBsACAAVABpAG0AZQAAAAAAAAAAAAAAAAAAAAAAAAAAACgAVQBUAEMAKQAgAEMAbwBvAHIAZABpAG4AYQB0AGUAZAAgAFUAbgBpAHYAZQByAHMAYQBsACAAVABpAG0AZQAAAAAAAAAAAAAAAAAAAAAAAAAAAA==</calendar:TimeZone>
<calendar:UID>20060416T204026Z-4272-727-1-244@gollum</calendar:UID>
<calendar:DTStamp>20060416T204026Z</calendar:DTStamp>
<calendar:StartTime>20060406T000000Z</calendar:StartTime>
<calendar:EndTime>20060407T000000Z</calendar:EndTime>
<calendar:BusyStatus>0</calendar:BusyStatus>
<calendar:Subject>all day event</calendar:Subject>
<calendar:Sensitivity>0</calendar:Sensitivity>
<calendar:AllDayEvent>1</calendar:AllDayEvent>
<calendar:Location></calendar:Location>
<calendar:Categories></calendar:Categories>
<calendar:Attendees></calendar:Attendees>
<airsyncbase:Body>
<airsyncbase:Type>1</airsyncbase:Type>
<airsyncbase:Truncated>0</airsyncbase:Truncated>
<airsyncbase:Data></airsyncbase:Data>
</airsyncbase:Body>
<calendar:Exceptions/>
</ApplicationData>
And this how it comes back:
<Response>
<Fetch>
<Status>1</Status>
<CollectionId xmlns="AirSync:">1</CollectionId>
<ServerId xmlns="AirSync:">1:19</ServerId>
<Class xmlns="AirSync:">Calendar</Class>
<Properties>
<TimeZone xmlns="Calendar:">LAEAACgAVQBUAEMALQAwADUAOgAwADAAKQAgAEUAYQBzAHQAZQByAG4AIABUAGkAbQBlACAAKABVAFMAIAAmACAAQwAAAAsAAAABAAIAAAAAAAAAAAAAACgAVQBUAEMALQAwADUAOgAwADAAKQAgAEUAYQBzAHQAZQByAG4AIABUAGkAbQBlACAAKABVAFMAIAAmACAAQ
wAAAAMAAAACAAIAAAAAAAAAxP///w==</TimeZone>
<DTStamp xmlns="Calendar:">20111207T110840Z</DTStamp>
<StartTime xmlns="Calendar:">20060406T000000Z</StartTime>
<Subject xmlns="Calendar:">all day event</Subject>
<UID xmlns="Calendar:">20060416T204026Z-4272-727-1-244@gollum</UID>
<Organizer_Name xmlns="Calendar:">pohly-activesync</Organizer_Name>
<Organizer_Email xmlns="Calendar:">pohly-activesync(a)syncevolution.org</Organizer_Email>
<Location xmlns="Calendar:"/>
<EndTime xmlns="Calendar:">20060407T000000Z</EndTime>
<Body xmlns="AirSyncBase:">
<Type>1</Type>
<EstimatedDataSize>0</EstimatedDataSize>
</Body>
<Sensitivity xmlns="Calendar:">0</Sensitivity>
<BusyStatus xmlns="Calendar:">0</BusyStatus>
<AllDayEvent xmlns="Calendar:">1</AllDayEvent>
<MeetingStatus xmlns="Calendar:">0</MeetingStatus>
<NativeBodyType xmlns="AirSyncBase:">1</NativeBodyType>
</Properties>
</Fetch>
</Response>
(process:5079:0xbbbe340): libeas-DEBUG:process timezone LAEAACgAVQBUAEMALQAwADUAOgAwADAAKQAgAEUAYQBzAHQAZQByAG4AIABUAGkAbQBlACAAKABVAFMAIAAmACAAQwAAAAsAAAABAAIAAAAAAAAAAAAAACgAVQBUAEMALQAwADUAOgAwADAAKQAgAEUAYQBzAHQAZQByAG4AIABUAGkAbQBlACAAKABVAFMAIAAmACAAQwAAAAMAAAACAAIAAAAAAAAAxP///w== => bias 300, standard bias 0, daylight bias -60, standard '(UTC-05:00) Eastern Time (US & C', daylight '(UTC-05:00) Eastern Time (US & C'
The same happens when syncing (instead of fetching) the item:
<Add>
<ServerId>1:6</ServerId>
<ApplicationData>
<TimeZone xmlns="Calendar:">LAEAACgAVQBUAEMALQAwADUAOgAwADAAKQAgAEUAYQBzAHQAZQByAG4AIABUAGkAbQBlACAAKABVAFMAIAAmACAAQwAAAAsAAAABAAIAAAAAAAAAAAAAACgAVQBUAEMALQAwADUAOgAwADAAKQAgAEUAYQBzAHQAZQByAG4AIABUAGkAbQBlACAAKABVAFMAIAAmACAAQwAAAAMAAAACAAIAAAAAAAAAxP///w==</TimeZone>
<DTStamp xmlns="Calendar:">20111207T110840Z</DTStamp>
<StartTime xmlns="Calendar:">20060406T000000Z</StartTime>
<Subject xmlns="Calendar:">all day event</Subject>
<UID xmlns="Calendar:">20060416T204026Z-4272-727-1-244@gollum</UID>
<Organizer_Name xmlns="Calendar:">pohly-activesync</Organizer_Name>
<Organizer_Email xmlns="Calendar:">pohly-activesync(a)syncevolution.org</Organizer_Email>
<Location xmlns="Calendar:"/>
<EndTime xmlns="Calendar:">20060407T000000Z</EndTime>
<Body xmlns="AirSyncBase:">
<Type>1</Type>
<EstimatedDataSize>0</EstimatedDataSize>
</Body>
<Sensitivity xmlns="Calendar:">0</Sensitivity>
<BusyStatus xmlns="Calendar:">0</BusyStatus>
<AllDayEvent xmlns="Calendar:">1</AllDayEvent>
<MeetingStatus xmlns="Calendar:">0</MeetingStatus>
<NativeBodyType xmlns="AirSyncBase:">1</NativeBodyType>
</ApplicationData>
</Add>
I'm out of ideas. Does anyone have an explanation for this inconsistent behavior?
I'm not even sure where the US Eastern time comes from. Remember, the
user's settings on the server is the UTC time zone. Is there perhaps
anything in the protocol where the device can tell the server what its
current time zone it?
The client first talked to the server when the setting still was Eastern
time. I suspected that the server might have permanently stored that
setting in its device database. But trying again with a different device
ID yields the same Eastern time.
The other inconsistency is in the all day time handling. As seen above,
when the server is set to UTC, it sends an UTC time zone and start/end
time with T000000Z.
When set to something else, for example Berlin, it sends start/end time
such that they align to midnight in that locality:
<TimeZone xmlns="Calendar:">xP///ygAVQBUAEMAKwAwADEAOgAwADAAKQAgAEEAbQBzAHQAZQByAGQAYQBtACwAIABCAGUAcgBsAGkAbgAsACAAQgAAAAoAAAAFAAMAAAAAAAAAAAAAACgAVQBUAEMAKwAwADEAOgAwADAAKQAgAEEAbQBzAHQAZQByAGQAYQBtACwAIABCAGUAcgBsAGkAbgAsACAAQgAAAAMAAAAFAAIAAAAAAAAAxP///w==</TimeZone>
<DTStamp xmlns="Calendar:">20111207T111753Z</DTStamp>
<StartTime xmlns="Calendar:">20060405T220000Z</StartTime>
<Subject xmlns="Calendar:">all day event Berlin</Subject>
<UID xmlns="Calendar:">040000008200E00074C5B7101A82E00800000000AEC226DDD1B4CC01000000000000000010000000FFEF41BB9D40704BAD4F70361DB9F092</UID>
<Organizer_Name xmlns="Calendar:">pohly-activesync</Organizer_Name>
<Organizer_Email xmlns="Calendar:">pohly-activesync(a)syncevolution.org</Organizer_Email>
<Location xmlns="Calendar:"/>
<EndTime xmlns="Calendar:">20060406T220000Z</EndTime>
(process:5572:0xbbbe9c0): libeas-DEBUG:process timezone xP///ygAVQBUAEMAKwAwADEAOgAwADAAKQAgAEEAbQBzAHQAZQByAGQAYQBtACwAIABCAGUAcgBsAGkAbgAsACAAQgAAAAoAAAAFAAMAAAAAAAAAAAAAACgAVQBUAEMAKwAwADEAOgAwADAAKQAgAEEAbQBzAHQAZQByAGQAYQBtACwAIABCA
GUAcgBsAGkAbgAsACAAQgAAAAMAAAAFAAIAAAAAAAAAxP///w== => bias -60, standard bias 0, daylight bias -60, standard '(UTC+01:00) Amsterdam, Berlin, B', daylight '(UTC+01:00) Amsterdam, Berlin, B'
This is converted correctly into:
DTSTART;VALUE=DATE:20060406
SUMMARY:all day event Berlin
DTEND;VALUE=DATE:20060407
So the conversion of all day times based on the time zone is necessary
here, but breaks the event quoted earlier. The only heuristic that I can
think of is to use the conversion only if the results align with
midnight.
--
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.
8 years, 1 month
