I always wondered, why there was no CalDav/CardDav synergy connector for webOS. CalDav is one of these web (or at least web-like) open standards that webOS usually uses.
Since some time webos-ports put some effort in creating a synergy connector for CardCav. The repository can be found here. The day I recognized that activity I got in touch with them and moved the connector forward quite a bit. Especially the CalDav part and that it is using the webOS Mojoservice-Sync-framework which takes away a lot of the pain doing a synergy connector was my idea and my work. Currently I am using the connector fine on my Veer and my wife’s Pre 3 for calendar and contact sync (contact only one way from server, calendar two way). I still have a private fork with more experimental version here.
The software sadly did not make its way yet into Preware or the App catalogue… you can apply as beta tester by contacting me ;-). I am still testing with my eGroupware server. Owncloud also seems to work fine, now. I did some rudimentary tests with Yahoo (calendar seems to be fine). Google Calendar is not yet working, though.
I think if webos ports gets this synergy connector into a stable release, open webos will solve one of it’s more pressing issues: That there are no synergy connectors delivered with it.
I must admit that I like the caldav connector that much, that I stopped using SyncML. Therefore that is bad news for all my SyncML using friends: further development of the SyncML connector is rather unlikely. SyncML support seems to be fading out in most server implementations, because CalDav is much easier to implement (actually it’s very similar to webdav and most is done by the webserver already…). A lot of the knowledge I gathered in writing the SyncML connector and quite some bits of the code did go into the CalDav connector. So I’m quite happy with the current situation. 🙂
Actually the most pressing issue in SyncML was the slow sync that did happen from time to time and liked to mess up my data a lot.
Maybe, if there are people that are really in need of the SyncML connector and can’t use anything else and are willing in testing (and risk loosing/messing up their data), I’ll reimplement the SyncML connector in the Mojoservice-Sync-framework also, which takes away some of the issues the SyncML connector always had. Till then it might benefit from some improvements in iCal/vCard parsing and generation. But nothing happened on this front, yet.
Just a short status update (I really need to configure Poster for this blog. ;)).
I implemented and published a first experimental contact sync. The contact sync currently has multiple issues:
- Character encoding issue (for example umlauts)
- Photos do not get synced at all
- Some servers (for example eGroupware) behave very strange. I believe this is, because they don’t know my app
- Contacts don’t show up on the TouchPad at all
The TouchPad issue is quite strange. The contacts are correctly stored in the database… the same code works fine on the phones. But on the TouchPad the contacts app and also Just Type won’t show the contacts at all. I need to investigate that further…
Currently I advise you to be very careful, if you use contact sync… maybe first try One-Way-From-Server sync.
BTW: I fixed an issue that made the app forget One-Way-From-Server (or similar) if the server requested a slow sync and made it switch to “Two-Way” sync. This is now fixed and slow sync will switch back to One-Way-From-Server correctly.
I’m making some progress with the SyncML client.
- add try/catch to all callbacks to receive notions of errors that happen. Especially look at iCal, eventCallbacks and SyncML. Maybe als SyncMLMessage.
- write to O3SIS and ask if they have an idea why their server (used by O2) does not accept my device information.
- work on js service implementation
- implement message retry mechanism, sometimes I only receive an empty response… 🙁
- test on funambol server and on http://www.o-sync.com
- supply the type of iCal to iCal.js, i.e. if it’s 1.0 = x-vcalendar or 2.0 = vcalendar. Do what you can for x-vcalendar conversion (not so easy).
- save global event id in externalId
Issues to look at:
- O2 server does not accept allDay events from the device (thought I had fixed that)
- look in “quoted_printable_decode/encode” to try to solve umlaut issues and similar
- does the webos calendar without patches allow to choose the colour of an calendar?
- eGroupware did send me duplicates of allDay events during a slow sync. Those were not duplicated on the server which means either I did not send them (or what I send was faulty) or…? Look into that. Maybe this was because of the ongoing timezone issue?
- see if funambol needs sync to “configuration” datastore for credentials checking or if my empty SyncMLMessage is sufficient… Example for funambol configuration sync:
Thoughts about contact sync:
Contacts Service has readVCard => can I call that?
Maybe need to write vCard parser myself. Does not seem more complicated than iCal parser. Some ressources:
or extensions mentioned in wikipedia.
This is also interesting: frameworks/contacts/…/vCard/vCard.js
Has importer, here I can set importToAccountId to my accountId and let it do all the work. There also is a importToContactSetId. Maybe that is useful to implement categories? Keep in mind for later… 😉
Let it return an array of contacts to the app, so I can do the add’s myself and supply the local ids to the server mapping. Also this seems necessary for updates instead of adds.
Interesting also: VCardImporter => processOneContact creates hashes to check for duplicates. Maybe that is a good thing to have in case something goes wrong?
Look what is the same for contacts and events and move that into common js files to make the single files smaller. It’s getting quite messy already. 🙁
Since a long time now I am using an eGroupware Server at home as my personal cloud. I tried some hacks to use it with webos, but none really worked out as I liked it. Most lead to data corruption and I always was required to leave my valuable data (what I’m doing everyday!!!) on big company servers like google.
SyncML on webOs 1.4.5
So I started a project to implement a SyncML Client for webOs, because SyncML worked good for me with Windows Mobile 5-6.5. I first tried to implement something based on some SyncML libraries. I managed to combile funambol for webOs and build a client app around that. It worked good for calendar syncs. But it never made me really happy. You need to manually fire up the app and start a sync and the sync is quite slow. There are some issues that reside deep inside the funambol library and in the iCal parsing I needed to do. Then this all was for webOs 1.4.5, which mostly was not usable for webOs 2.x anymore that my new phones are all using (only my old Pixi Plus is on 1.4.5, still and comes with me as second phone just for calendar syncs since some time now). I won’t work on SyncML for webOs 1.4.5 anymore, but you can get the code and an ipkg here.
SyncML on webOs 2.x
As I said, my 1.4.5 version won’t work on webOs 2.x. I fixed it to basically run on 2.x (you can view that here) but never managed to fix the issues I had. There were bad conversion issues from iCal to the new calendar event structure in webOs 2.x.
It’s far from finished and still has the old app interface, but it is on a good way forward. You can have a look at it here.
My list of Todo’s
- Build synergy integration
- Build service for that
- Rebuild App to use the service (for easier debugging)
- Test the service
- Modify account management and sync management for better integration of calendar and contacts to add more datastores
- Implement contacts sync (will require new or extended parser)
- Modify app to view service logs and allow to send them per E-Mail
- Optimize old eventCallback structure to be more database optimized and collect all adds, updates and deletes to do them in one batch.
- Try to respect server max msg size by only adding like 10 objects to a message (currently sends all in one message and has reached like 20kb which is way over the server advertised limit of 10kb. Luckily that does not matter much to the server, as it seems).