[sync] More on m600i

[Alex Masidlover]

Hi Karsten,

> sorry for taking so long to respond. But I've been on vacation for a
> while (bella italia).

No problem, hope you had a good holiday.

> Many Thanks for the detailed infos on the m600i. I'll have a look at it
> and try to come up with something. However there's quite a bit of
> backlog in my inbox :-(

I know that feeling!

> Here's a bit of quick feedback without further investigation:
>> md5 auth does not currently set login state. (previously reported to list)
> should be easy to fix

I was going to take a look at how easy it would be to fully implement  
md5 authing and submit some patches if I can figure something out. In  
the meantime I've reported the 'bug' (4463) and my temporary fix.

>> Alert states do not seem to work - particularly the NEXT_MESSAGE   
>> state is required by the m600i. (previously reported to list)
> right. I only encountered NEXT_MESSAGE in the sync4j beta outlook
> connector. And there it was used in a imho very much spec violating
> way. So I was reluctant to implement it yet. But with a valid example
> from the m600i i can put it in.

I've submitted a bug and sample of xml in bug 4464.

>> In later tests
>> the m600i also requested a slow sync with an alert and this seemed   
>> to drop Horde into the same problem (database name not recognised).

The following error appeared when the phone sent an Alert cmd (also  
happened when I tried implementing NEXT MESSAGE within the Alert case  
statements):

HORDE [error] [horde] SyncML: Invalid db name: . Try tasks, calendar,  
notes or contacts. [on line 38 of  
"/usr/share/php/SyncML/Command/Alert.php"]

I haven't managed to reproduce this so have not yet reported it as a  
bug, but if I can reproduce it I will do so.

>> The 50 byte allowance on MaxMsgSize to see whether to add data to a  
>>  package is not large enough for my contacts data - I had to push  
>> it  to over 2000 before I could get it to work reliably. I would  
>> think  the ideal behaviour would be for it to be able to back out  
>> the last  entry if it hits the limit.
> The idea was that the size of the current item is taken into account
> and the 50 byte allowance only for closing XML tags (</SyncML> and so
> on). Maybe it's not working as intended. I'll have a look

I pushed the allowance from 50 -> 100 -> 1000 -> 3000, and got various  
over shoots from 180 -> 900 bytes until I got to 3000 when it worked  
perfectly. If you want I'll send you the files but would have to do it  
off list since it is real contact data.

>> The m600i expects calendar and tasks to come across as one   
>> database/application - I can't see that their is any coding to   
>> allow Horde to send like this (although it looks like it can   
>> receive mixed events).
> My old P900 did it the same way. The device.php has a
> "handleTasksInCalendar()" because of this. We'll have to set it to true
> for the m600i.

The device appears to be being handled as a P800 according to the log.  
Would this handling apply to transfer from the server (as well as from  
the device); if so something is not quite right since I have tasks on  
the server which are not transferring to the device.

>> Also I had an odd problem which I haven't been able to reproduce -   
>> usually the pattern is that the client sends a package; the wbxml   
>> turns up in /tmp/sync and the log shows a new/existsing session   
>> message. Then the server generates a wbxml package and ends its log  
>>  entries 'return message completed'. However on one occasion it ran  
>>  through 4 or 5 exchanges and then the log showed a 'return message  
>>  completed' and nothing further despite the last package being   
>> received
>>> from the client and placed in /tmp/sync (when there should have been
>> an existing session continued message in the log).
> Anything in the php error log?

I don't have a separate PHP log set-up and can't find anything in  
apache's error logs - I've turned on PHP error logging so I can spot  
anything if it happens again.

>> I've only got the phone for a few days more and I don't think any   
>> of these issues are easy fixes (at least not for me!).
> I think we can do this :-)

Let me know what further tests you want running in the short term  
before I send back this unit - I'm pretty impressed with the device  
and will be buying myself one before long so will be able to test any  
changes.

Alex

-- 
Open Source Specialist
Axiom Tech Limited
W: http://www.axiomtech.co.uk
T: 0845 1270316 or +44 161 660 8009



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.