opensync-devel

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Chris F. <cd...@fo...>]

On Fri, Dec 09, 2011 at 10:30:43AM +0100, deloptes wrote:
> OK, so here is something interesting to start with.
> I've got the framework to compile and link. Also the basic opensync related
> stuff. At this point I am not calling any synthesis functions as it needs
> to be configured first ...

I'm curious how it functions with the synthesis calls in there. :-)


> =       osynctool --discover synth1    =
> EKO: get_sync_info:
> EKO: get_sync_info:
> EKO: get_sync_info:

I think these are from osynctool's group and format initialization.


> EKO: synthml_http_client_initialize
> EKO: httpClientSink->initialize() DONE
> EKO: connect to Synthesis
> EKO: OSyncObjTypeSink#contact
> EKO: initializing: contact
> EKO: synthml_discover: 1
> EKO: DevInf or similar asking the engine to provide information
> EKO: foreach collection
> EKO: configure ressource
> EKO: synthml_http_client_finalize:
> EKO: disconnect from Synthesis
> EKO: synthml_http_client_finalize: DONE
> Discovered Objtypes:
>         contact
>                 Format: vcard21
>                 Format: vcard30
> EKO: get_sync_info:
> EKO: get_sync_info:
> Discovered Objtypes:
>         contact
>                 Format: file

Not sure about these, but discovery is in a loop in osynctool...


> And something C/C++ related - where can I read about it, or can you answer
> briefly here. there is this extern C {} block and inside I can use
> std::cout << ...;
> How is this all handled by the compiler and/or processor so that it works
> from C. I would say it is the compiler that is doing the magic ... but I'm
> too curious to know what actually happens. In the book it says briefly, it
> is providing access to C++ functions from C.

You can use any C++ code, even in C++ functions called from C.  What you
do _not_ want to have happen is for C++ exceptions to escape back into
C land.

So... in your C++ code:

	extern "C" {
		void cppfoo();
	}

	void cppfoo()
	{
		try {
			cout << "Hello world!" << endl;

			SomeClass obj;
			obj.ThisThrows();
		}
		catch(...) {
			cout << "Exception in C++ code!" << endl;
		}
	}

And in your C code, which is blissfully unaware of exceptions:

	cppfoo();

If you need examples of this, check out the Barry opensync plugins.

- Chris

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[deloptes <del...@ya...>]

Chris Frey wrote:

> On Fri, Dec 09, 2011 at 10:30:43AM +0100, deloptes wrote:
>> OK, so here is something interesting to start with.
>> I've got the framework to compile and link. Also the basic opensync
>> related stuff. At this point I am not calling any synthesis functions as
>> it needs to be configured first ...
> 
> I'm curious how it functions with the synthesis calls in there. :-)
> 

Here is 1 example with 1 call sysync::UI_Connect. This synthesis stuff is
still confusing to me :-). It looks like it will require more time to
understand it :-)

=       osynctool --discover synth1    =
EKO: osync_bool get_sync_info(OSyncPluginEnv*, OSyncError**)
EKO: osync_bool get_sync_info(OSyncPluginEnv*, OSyncError**)
EKO: osync_bool get_sync_info(OSyncPluginEnv*, OSyncError**)
EKO: void* synthml_http_client_initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**)
EKO: bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*,
OSyncPluginInfo*, OSyncError**)
EKO: virtual void OSynthML::SynthmlHttpClient::connect()connect to Synthesis
EKO: sysync::TSyError sysync::UI_Connect(sysync::SDK_InterfaceType*&,
void*&, bool&, sysync::cAppCharP, sysync::CVersion, sysync::uInt16)
EKO: void* synthml_http_client_initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**) OSyncObjTypeSink#contact
EKO: bool OSynthML::DataSink::initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncObjTypeSink*, OSyncError**) initializing: contact
EKO: bool OSynthML::DataSink::initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncObjTypeSink*, OSyncError**) DONE
EKO: void* synthml_http_client_initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**) DONE
EKO: osync_bool synthml_discover(SYNTHML_PLUGIN_TYPE, OSyncPluginInfo*,
void*, OSyncError**)Plugtype OBEX, CLIENT, SERVER: 1
EKO: osync_bool testSupport(OSyncObjTypeSink*, OSyncPluginConfig*,
std::string, OSyncError**)
EKO: osync_bool testSupport(OSyncObjTypeSink*, OSyncPluginConfig*,
std::string, OSyncError**) DevInf or similar asking the engine to provide
information
EKO: osync_bool testSupport(OSyncObjTypeSink*, OSyncPluginConfig*,
std::string, OSyncError**) foreach collection
EKO: osync_bool testSupport(OSyncObjTypeSink*, OSyncPluginConfig*,
std::string, OSyncError**)> configure ressource
EKO: osync_bool testSupport(OSyncObjTypeSink*, OSyncPluginConfig*,
std::string, OSyncError**) DONE
EKO: void synthml_http_client_finalize(void*) START
EKO: virtual void OSynthML::SynthmlHttpClient::disconnect() disconnect from
Synthesis
EKO: void synthml_http_client_finalize(void*) DONE
Discovered Objtypes:
        contact
                Format: vcard21
                Format: vcard30
EKO: osync_bool get_sync_info(OSyncPluginEnv*, OSyncError**)
EKO: osync_bool get_sync_info(OSyncPluginEnv*, OSyncError**)
Discovered Objtypes:
        contact
                Format: file

>> EKO: get_sync_info:

the first 3 are for each plugin
and the last are perhaps for each format 1 call 

thanks ... it's juts curiosity and no time to check the code :-)

> 
> 
>> And something C/C++ related - where can I read about it, or can you
>> answer briefly here. there is this extern C {} block and inside I can use
>> std::cout << ...;
>> How is this all handled by the compiler and/or processor so that it works
>> from C. I would say it is the compiler that is doing the magic ... but
>> I'm too curious to know what actually happens. In the book it says
>> briefly, it is providing access to C++ functions from C.
> 
> You can use any C++ code, even in C++ functions called from C.  What you
> do _not_ want to have happen is for C++ exceptions to escape back into
> C land.
> 
> So... in your C++ code:
> 
> extern "C" {
> void cppfoo();
> }
> 
> void cppfoo()
> {
> try {
> cout << "Hello world!" << endl;
> 
> SomeClass obj;
> obj.ThisThrows();
> }
> catch(...) {
> cout << "Exception in C++ code!" << endl;
> }
> }
> 
> And in your C code, which is blissfully unaware of exceptions:
> 
> cppfoo();
> 
> If you need examples of this, check out the Barry opensync plugins.
> 

Thanks I think I understand better.

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Chris F. <cd...@fo...>]

On Fri, Dec 09, 2011 at 08:00:58PM +0100, deloptes wrote:
> EKO: bool OSynthML::DataSink::initialize(OSyncPlugin*, OSyncPluginInfo*,
> OSyncObjTypeSink*, OSyncError**) initializing: contact

Is this libsynthesis calling you?  i.e. is this a callback?

- Chris

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[deloptes <del...@ya...>]

Chris Frey wrote:

> On Fri, Dec 09, 2011 at 08:00:58PM +0100, deloptes wrote:
>> EKO: bool OSynthML::DataSink::initialize(OSyncPlugin*, OSyncPluginInfo*,
>> OSyncObjTypeSink*, OSyncError**) initializing: contact
> 
> Is this libsynthesis calling you?  i.e. is this a callback?
> 

No I have not implemented this yet. I was thinking DataSink should use the
DB API and act as plugin to the synthesis engine, but reading the
documentation I think the UI API is what we need as we are driving the
engine.

"With the SySync UIApi SDK, the customer can write his own user interface
and communication code (in the current version for SyncML available for
client applications) and is calling the SyncML engine for initialization,
syncing, message reading/writing and parameter setup. In this
configuration, the UI application is usually a program which acts as master
and is using the SyncML engine as shared (or linked) library." (p.7
SDK_manual)

In contrast to:

"With the SySync DBApi SDK, the customer is able to create plug-ins, which
will be called directly by the Synthesis SyncML engine. The SyncML engine
acts as a master: It makes subroutine calls into the plugin DLL. Each
routine must return an error status, which will be handled by the engine.
The main three blocks are the Module, the Session and the Datastore
handling. These three blocks are normally kept within one DLL, but they can
be separated into different DLLs as well. The description of each routine
with several programming hints can be found in the interface definition
file „sync_dbapi.h“."

So we want in a global scale from the plugin perspective do the following: 
1. initialize the plugin in the osync engine
2. start the synthesis engine (we are the application)
3. connect the phone or act as whatever SyncML client/server
4. sync (get changes etc)
5. disconnect
6. stop the engine
7. finalize the plugin in the osync engine

I need to get a picture of the details now. Of course any help is
appreciated.

regards

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Chris F. <cd...@fo...>]

On Fri, Dec 09, 2011 at 11:17:16PM +0100, deloptes wrote:
> No I have not implemented this yet. I was thinking DataSink should use the
> DB API and act as plugin to the synthesis engine, but reading the
> documentation I think the UI API is what we need as we are driving the
> engine.

I believe we need both, if I'm understanding the DB API correctly.

We need the UI API to run the engine, and do the sync.  But we need the
DB API to provide something for the synthesis engine to sync to.

i.e. somehow we need to get at the low level contact data, and I'm guessing
this is only available via the DB API.

If so, then the DB API will be syncing into some database that we can read
for when opensync needs to sync to it.


	osynctool -> Opensync engine -> your_plugin -> UI API -> libsynthesis engine -> ??? -> DB API -> your_libsynthesis_plugin

"your_plugin" has access to all of opensync's data.  "your_libsynthsis_plugin"
has access to the synthesis data.  How to make these sets of data meet
is the challenge.

- Chris

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[deloptes <del...@ya...>]

Chris Frey wrote:

> On Fri, Dec 09, 2011 at 11:17:16PM +0100, deloptes wrote:
>> No I have not implemented this yet. I was thinking DataSink should use
>> the DB API and act as plugin to the synthesis engine, but reading the
>> documentation I think the UI API is what we need as we are driving the
>> engine.
> 
> I believe we need both, if I'm understanding the DB API correctly.
> 
> We need the UI API to run the engine, and do the sync.  But we need the
> DB API to provide something for the synthesis engine to sync to.
> 
> i.e. somehow we need to get at the low level contact data, and I'm
> guessing this is only available via the DB API.
> 
> If so, then the DB API will be syncing into some database that we can read
> for when opensync needs to sync to it.
> 
> 
> osynctool -> Opensync engine -> your_plugin -> UI API -> libsynthesis
> engine -> ??? -> DB API -> your_libsynthesis_plugin
> 
> "your_plugin" has access to all of opensync's data. 
> "your_libsynthsis_plugin"
> has access to the synthesis data.  How to make these sets of data meet
> is the challenge.
> 

This was also my original plan, but after reading again from the beginning I
understand either is possible, which means the UI API provides the
necessary functions to access the data and put it somewhere, though now I
think my original plan was still better

So modified version of the previous plan:

1. initialize the plugin in the osync engine
2. start the synthesis engine (UI)
3. connect the phone or act as whatever SyncML client/server (DB? or UI?)
4. sync (get changes etc) - provide a syncml plugin (DB)
5. disconnect (DB? or UI?)
6. stop the engine (UI)
7. finalize the plugin in the osync engine

I'll check this 

thanks