[sync] More on m600i

[Alex Masidlover]

Right, I've got the m600i synchronising, as I see it the issues with  
this phone/Horde are:

md5 auth does not currently set login state. (previously reported to list)

Alert states do not seem to work - particularly the NEXT_MESSAGE state  
is required by the m600i. (previously reported to list) 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 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.

Sycning all the contacts and calendar (500+ entries) crashes the  
phone. Syncing separately for the first sync and the together for  
subsequent Syncs works fine.

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).

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).

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'm happy to  
generate the test cases against my hacked version of Horde if that  
will be any help - but I don't think my hacks are really suitable for  
production.

The only one I might have time to take a look at would be the md5 auth  
and try and implement that (at least against the LDAP back end which  
we use).

Hope this is of some use, if only to other people needing to hack  
support for the m600i...

Alex

>>> I've tried simply adding it to the list of cases and setting      
>>> $response and $synctype to sensible values RESPONSE_OK and      
>>> ALERT_TWO_WAY. Unfortunately it fails at early on when it checks    
>>>   that $this->_targetLocURI has a valid database name, which it     
>>>  doesn't - I may be missing something but I can't find a member of  
>>>     SyncML_Command or SyncML_Command_Alert by that name.
>>
>> It may have been factored out - Karsten will have to weigh in here.
>
> A quick and very dirty solution occured to me; what happens if Horde
> simply ignores the NEXT MESSAGE alert? I stuck a return in if the
> _alert matches ALERT_NEXT_MESSAGE and the m600i synchronises the
> calendar! Contacts has just come back with a 'too big' message but I
> think I can fix that by playing with the 50 byte margin that is
> applied to the MaxMsg size testing (will report back later on that).
>
>>> I've also taken a look at the e-groupware changes to the SyncML     
>>>  implementation (which does have NEXT MESSAGE), however the  
>>> changes     to Alert (and probably the rest) are pretty extensive  
>>> and would     probably take an expert in either Horde or  
>>> eGroupware (or both)  to    port across.
>>
>> This doesn't address your problem, but: Grrr! I was given every
>> impression that the eGroupWare folks were going to contribute changes
>> and fixes back to us. Care to poke them about that?
>
> I'll try and politely request some help with the NEXT_MESSAGE issue
> quouting their offers to contribute back and see what happens.
>

-- 
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.