[sync] More on m600i

[Karsten Fourmont]

Hi Alex,

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

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 :-(


Here's a bit of quick feedback without further investigation:

Alex Masidlover wrote:
> md5 auth does not currently set login state. (previously reported to list)
should be easy to 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.

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


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

> 
> 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'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 :-)

 > 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.
> 
> --sync mailing list - Join the hunt: http://horde.org/bounties/#sync
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: sync-unsubscribe at lists.horde.org