Re: partial sync with nokia 6021
Hristo Hristov <[email protected]>
| Newsgroups | gmane.comp.horde.sync |
|---|---|
| Message-ID | <[email protected]> |
On Thursday 07 May 2009 18:50:28 Jan Schneider wrote: > Zitat von Hristo Hristov <[email protected]>: > > Hello there, > > > > On Friday 01 May 2009 00:31:37 Jan Schneider wrote: > >> Please keep discussions on the list. > > > > Sorry for that, didn't mention that Re: is not on the list. > > > >> Zitat von Hristo Hristov <[email protected]>: > >> > On Wednesday 29 April 2009 20:19:48 you wrote: > >> >> Zitat von Hristo Hristov <[email protected]>: > >> >> > Hello list, > >> >> > > >> >> > I've installed most recent stable version of horde platform. Here > >> >> > is the list of applications I'm using. > >> >> > > >> >> > === > >> >> > Address Book (turba) H3 (2.3.2-cvs) > >> >> > Calendar (kronolith) H3 (2.3.1) > >> >> > Dynamic Mail (dimp) H3 (1.1.2) > >> >> > Horde (horde) 3.3.3 > >> >> > Mail (imp) H3 (4.3.4) > >> >> > Mobile Mail (mimp) H3 (1.1.2-cvs) > >> >> > Notes (mnemo) H3 (2.2.2-cvs) > >> >> > Photos (ansel) H3 (1.0.1-cvs) > >> >> > Tasks (nag) H3 (2.3.2) > >> >> > === > >> >> > > >> >> > I have the following problem with underlaying SyncML > >> >> > implementation. There is successful start of synchronization > >> >> > session with Nokia 6021 phone. All entries from phone's address > >> >> > book are copied (synchronized) with horde, but unfortunately phone > >> >> > yields "Synchronization failed" message, with underlaying failure > >> >> > for Contacts, Calendar and Notes items. > >> >> > > >> >> > There is no errors in php's error log. I'm also attaching a .tar > >> >> > containgin /tmp/sync files. > >> >> > > >> >> > I had also such "bad" experience with other nokia phones, but can't > >> >> > send a full sync logs right now. > >> >> > > >> >> > As it is visible for me, server sends all messagages correctly and > >> >> > completes sync session. May be nokia phones want something > >> >> > additional in order to account sync session as successfully > >> >> > completed. > >> >> > > >> >> > Are there any chance for improper device info handling from server > >> >> > side? Please give additional "direction" to look for in order to > >> >> > fix the problem. > >> >> > > >> >> > Hristo > >> >> > >> >> The logs are perfectly fine, as is the last syncml package sent to > >> >> the phone. Unless the phone is giving an error message that is > >> >> actually useful, there are not many chances to dig down the problem. > >> >> Maybe the phone times out? > >> >> > >> >> Jan > >> >> . > >> > > >> > Thank you for your replay. > >> > > >> > Initially I was thinking about MaxMsgSize tag. Phone is reporting > >> > something the following: > >> > > >> > <MaxMsgSize>3584</MaxMsgSize> > >> > > >> > All .wbxml files sent back from horde a smaller than this. But when > >> > they are unpacked, the final message is about 2 times larger than > >> > specified size. So this was my initial guess. > >> > > >> > On the other hand, definitely a kind of "time out" on phone side > >> > happends, because not all entries are copied form phone to server. > >> > > >> > Right now I can't test with smaller address book /don't have a place > >> > to copy all the contacts/, but I think this could resolve my problem. > >> > > >> > If you let me to ask one more question: > >> > Is there a proper handling of MaxMsgSize tag on horde's side? I.e. > >> > does horde's syncml implementation account this tag and send proper > >> > sized packages to client side? I was looking at mail list/bug archives > >> > and saw that there is a initial work on the subject. > >> > >> Yes, this is implemented. > >> > >> > One more thing: Do you plan a future release of horde's syncml > >> > implementation? > >> > And If yes, I'm definitely willing to help :) /with code(ing) || > >> > test(ing)/ > >> > >> What do you mean? We create new Horde releases all the time, I just > >> rolled another one. And almost every release contains some > >> improvements in the SyncML code. > > > > More precisely the following: > > > > 1) automatic registration for unexisting horde users: > > for example - user is attempting to sync, but doesn't exist in horde's > > user database, so backend automatically creates necessary user data; > > This has nothing to do with synching, this has to be implemented in > the authentication backend. And it's a pretty bad idea. Yes, it is so. I was thinking in terms of easier user registration. > > > 2) per user sync logging: > > syncml logs to be orderder in 'username' directories under /tmp/sync > > directory. > > Sync logging is a debug feature. There is no need for any fancyness. > You should turn it off in production anyway. Absolutely, but it can be also helpful for debuggin user problems, as almost every user uses different mobile device. > > > For the third thing i need a little description. Today I tested two > > more nokia > > phones, particularly '6300' and '5000d-2'. > > Both end syncml communication with the following error message 'Data > > Transfer Not Possible'. > > There was no errors in sync logs. But I noticed that both sides send > > different > > preferred 'devinfo' parameters. > > > > Sync logs can be found at: > > http://es2.nat.bg/~lisp/sync.Nokia-5000d-2/ > > > > client say's: > > <DataStore> > > <SourceRef>/telecom/pb.vcf</SourceRef> > > <MaxGUIDSize>8</MaxGUIDSize> > > <Rx-Pref> > > <CTType>text/x-vcard</CTType> > > <VerCT>2.1</VerCT> > > </Rx-Pref> > > <Tx-Pref> > > <CTType>text/x-vcard</CTType> > > <VerCT>2.1</VerCT> > > </Tx-Pref> > > <SyncCap> > > <SyncType>1</SyncType> > > <SyncType>2</SyncType> > > <SyncType>4</SyncType> > > <SyncType>6</SyncType> > > <SyncType>7</SyncType> > > </SyncCap> > > <Rx> > > <CTType>text/x-vcard</CTType> > > <VerCT>3.0</VerCT> > > </Rx> > > <Tx> > > <CTType>text/x-vcard</CTType> > > <VerCT>3.0</VerCT> > > </Tx> > > ... > > </DataStore> > > > > and server responds (on <Get> request): > > > > <DataStore> > > <SourceRef>contacts</SourceRef> > > <Rx-Pref> > > <CTType>text/directory</CTType> > > <VerCT>3.0</VerCT> > > </Rx-Pref> > > <Rx> > > <CTType>text/x-vcard</CTType> > > <VerCT>2.1</VerCT> > > </Rx> > > <Tx-Pref> > > <CTType>text/directory</CTType> > > <VerCT>3.0</VerCT> > > </Tx-Pref> > > <Tx> > > <CTType>text/x-vcard</CTType> > > <VerCT>2.1</VerCT> > > </Tx> > > <SyncCap> > > <SyncType>1</SyncType> > > <SyncType>2</SyncType> > > <SyncType>3</SyncType> > > <SyncType>4</SyncType> > > <SyncType>5</SyncType> > > <SyncType>6</SyncType> > > </SyncCap> > > </DataStore> > > Can this be the reason for misunderstanding and unsuccessfully > > communication between both sides? > > No. > > > So my 3rd point/proposal is for device specific 'devinfo' handling for > > different device types. One for Nokia (or more, if there are so much > > differences between different models) and another for Sony-Ericson. > > That's the purpose of devinfo. And it's a mandatory feature of syncml > servers. I suppose devinfo support is correctly implemented in horde's syncml backend, as it strictly follows SyncML specification. So I suppose the problem is in device software and my be update will fix the problem (or at lest I hope so). Where is situated the code which accounts user's device devinfo settings? As long as devinfo output form horde's side is implemented in /usr/share/php/SyncML/XMLOutput.php, do you think any 'investigation' in terms of 'put back to nokia, what it expects' may be helpful? Hristo > > Jan. -- sync mailing list - Join the hunt: http://horde.org/bounties/#sync Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: [email protected]