Ticket #196 (assigned defect)

Opened 2 years ago

Last modified 7 months ago

SyncML plugin should obey devinf

Reported by: jkloetzke Assigned to: abauer (accepted)
Priority: normal Milestone:
Component: Plugin: syncml Version: 0.31
Severity: normal Keywords:
Cc: bellmich

Description

For correct SyncML behavior the plugin should obey the devinf. As I understand this requires the following things to be implemented:

1) Store the devinf somewhere.

As the device may only send it's devinf in the first session it has to be stored somewhere. Maybe the opensyc engine should provide a common functionality for that.

2) Pass the devinf to smlDevInfConfigureSession

3) Truncate the uid's which are sent to the device if necessary (MaxGUIDSize).

4) Filter vcard/vcal attributes according to <CTCap> entries.

The actual filtering should not be done by the SyncML plugin. Maybe the common formats could register filter functions. The syncml plugin could then create appropriate filters and pass the <CTCap> data as config to the filter functions.

Is there any way I could help efficiently to accomplish that?

Change History

06/02/06 15:26:24 changed by ehabkost

  • owner changed from ehabkost to abauer.

Reassigning to Armin. I am not actively working on the SyncML plugin.

09/07/06 17:48:01 changed by abauer

  • status changed from new to assigned.
  • version set to 0.31.

11/21/07 21:16:34 changed by felixmoeller

  • cc set to bellmich.

It seems like bellmich did somework on devinf for the syncml-http-client. Maybe he can comment here.

11/22/07 10:52:45 changed by bellmich

I implemented a new devinf interface to libsyncml because syncml-http-client acts as a real syncml client. So the plugin must send the devinf stuff. Actually there are some issues with my new code:

1. I have to read the specs regarding Tx/Rx(-Pref) and implementing it's correct usage in the plugin (important for correct vCal/iCal handling).

2. Some plugin functions only rely on objformat to return the content type (this is wrong).

Storing a received devinf requires a serialization/deserialization API (perhaps via the already existing XML parser/assembler) and a storage place. I prefer the filesystem to allow manual manipulation ;)

Sorry, that I have not more ideas on this issue because I'm focussing on the client side because "my partner" is an OCS. Nevertheless I'm thinking about using OpenSync? as a bridge (syncing bluetooth enabled WLAN-less mobiles with central SyncML servers).

... but this will take some time ...

01/08/08 13:03:52 changed by bellmich

The first point of the ticket is fixed. The DevInf? is stored by the SynML plugin in a database. The next step would be some code to load the DevInf? from the database and configure the DevInfAgent? and the active SyncML session.

01/15/08 16:48:42 changed by bellmich

I completed the part which I can do. The SyncML plugin supports device information caching now (r333). Additionally the plugin explicitly requests the device information if the client does not send one and the plugin does not find the device in the cache.

The cache is a file called devinf.db in the directory of the plugin. Usually this is something like $HOME/.opensync/group*/*/devinf.db. This is SQLite database which is managed via osync_db_* functions. So you can take a look at your mobile's configuration even if you are not in debug/trace mode.