headers
Patrick Ohly | 1 Oct 2009 12:12
Picon
Favicon
Gravatar

Re: libsynthesis_srv

On Sat, 2009-09-26 at 21:21 +0100, Patrick Ohly wrote:
> On Sat, 2009-09-26 at 15:02 +0100, Lukas Zeller wrote:
> > On Sep 25, 2009, at 15:13 , Patrick Ohly wrote:
> > 
> > > On Tue, 2009-09-22 at 15:53 +0100, Lukas Zeller wrote:
> > >> To make both server and client libraries linkable into the same app,
> > >> libsynthesis_srv defines a different prefix for the entry points:
> > >> SySync_srv_xxxxx (defined in
> > >> serverengine_opensource_linux_prefix.h),
> > >> as opposed to SySync_xxxxx for the client variant.
> > >
> > > "linkable into the same app" only works when using shared libraries.  
> > > In
> > > static libraries there still would be plenty of name clashes, wouldn't
> > > they?
> > 
> > Why? The only symbols that need to be global/external  
> > xxx_ConnectEngine and xxx_DisconnectEngine which will not clash due to  
> > the prefix. All other symbols and class names should be local symbols  
> > of the library and not cause clashes with anything in other libs,  
> > IMHO. Or am I totally wrong with the way static libs work in Linux?
> 
> I'm afraid static libraries don't have "local symbols". Think of it as
> linking all object files from both libs into the same executable and you
> get the right idea about the kind of name clashes that would occur.
> 
> Speaking of name clashes, perhaps this can be avoided with a little
> dirty trick: when compiling the server, redefined the word "sysync" to
> "sysyncserver". This changes the namespace and thus the name of all
> global symbols, avoiding name clashes between the two versions of the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Lukas Zeller | 1 Oct 2009 12:36
Picon
Favicon
Gravatar

Re: libsynthesis_srv

Just to avoid too much parallel work:

I'm working hard to create a real unified version this very day (but  
it's all but trivial, might still take some time).

So if your approach is quick to apply and test, go ahead. But don't  
invest much time. But be aware that the unified version will be a huge  
commit touching the majority of files, moving code around and change  
many class names - I'm not likely to be able to merge another set of  
global changes with that.

Lukas

On Oct 1, 2009, at 12:12 , Patrick Ohly wrote:

> On Sat, 2009-09-26 at 21:21 +0100, Patrick Ohly wrote:
>> On Sat, 2009-09-26 at 15:02 +0100, Lukas Zeller wrote:
>>> On Sep 25, 2009, at 15:13 , Patrick Ohly wrote:
>>>
>>>> On Tue, 2009-09-22 at 15:53 +0100, Lukas Zeller wrote:
>>>>> To make both server and client libraries linkable into the same  
>>>>> app,
>>>>> libsynthesis_srv defines a different prefix for the entry points:
>>>>> SySync_srv_xxxxx (defined in
>>>>> serverengine_opensource_linux_prefix.h),
>>>>> as opposed to SySync_xxxxx for the client variant.
>>>>
>>>> "linkable into the same app" only works when using shared  
>>>> libraries.
>>>> In
(Continue reading)

Permalink | Reply | 3 comments |
headers
Patrick Ohly | 1 Oct 2009 12:58
Picon
Favicon
Gravatar

Re: libsynthesis_srv

On Thu, 2009-10-01 at 11:36 +0100, Lukas Zeller wrote:
> Just to avoid too much parallel work:
> 
> I'm working hard to create a real unified version this very day (but  
> it's all but trivial, might still take some time).
> 
> So if your approach is quick to apply and test, go ahead.

If I don't have to worry about getting it right on all platforms, then
the change is fairly simple, so I think I'll go ahead with it.

>  But don't  
> invest much time. But be aware that the unified version will be a huge  
> commit touching the majority of files, moving code around and change  
> many class names - I'm not likely to be able to merge another set of  
> global changes with that.

That won't be necessary, as the unified version will supersede whatever
intermediate solution I come up with. I'll make it so that I commit the
parts which may remain valid (SDK "server:" switch, some configure
options) separately from the parts which might have to be reverted
(extern "C").

--

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Ohly | 1 Oct 2009 13:01
Picon
Favicon
Gravatar

Re: libsynthesis_srv

On Thu, 2009-10-01 at 11:36 +0100, Lukas Zeller wrote:
> So if your approach is quick to apply and test, go ahead. But don't  
> invest much time. But be aware that the unified version will be a huge  
> commit touching the majority of files, moving code around and change  
> many class names - I'm not likely to be able to merge another set of  
> global changes with that.

I forgot to mention that the code currently compiles only with quite a
few warnings on my 64 bit Linux installation. I'll wait for this code
restructuring before addressing the compiler warnings, because that
would be impossible to merge.

--

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
Permalink | Reply | 1 comment |
headers
Patrick Ohly | 1 Oct 2009 14:27
Picon
Favicon
Gravatar

Re: libsynthesis_srv

On Wed, 2009-09-30 at 13:46 +0100, Beat Forster wrote:
> I think your proposal is fine, no objections for that.
>
> To make sure that I understand you correctly:
> - You're using "server:" as a keyword to be parsed out as server flag.
> - In case of built-in, the flag will be used to change the entry point name
>    ("SySync_srv_ConnectEngine"/"SySync_srv_DisconnectEngine")

Correct. This will be necessary in particular once Lukas merges both
versions of the engine into the same library.

> - In case of a library, the flag will be used to change the library name,
>    BUT ALSO the entry point name to have it consistent for both cases.

In case of a library the app still chooses the name itself. Only the
entry point is affected.

> Yes, it would nice if you come up with a patch proposal.
> If I understand your proposal correctly, you plan 
> to adapt the sources at UI_Connect/UI_Disconnect 
> at UI_util.cpp only for this ?

That, and the corresponding calls in enginemodulebridge. I wasn't quite
sure what to do about UI_CreateContext(), though. Where is the
corresponding disconnect? The disconnect needs to know which entry point
was used for connecting, as in the enginemodulebridge.

I've pushed all of my changes into the "server" branch on moblin.org.
This includes all changes which were necessary to avoid name clashes due
to extern "C". My suggestion is to wait with merging until Lukas has
(Continue reading)

Permalink | Reply | 4 comments |
headers
Patrick Ohly | 1 Oct 2009 15:26
Picon
Picon
Gravatar

unresponsive clients

Hello!

In your experience, what are good timeouts for aborting a SyncML session
in a server when a client stops sending messages?

Suppose a client wants to start a SyncML session while the server still
thinks that the client is still running an old session? I believe this
is something that has to be handled outside of the core engine, right?

One of our observations with suspend/resume tests was that the Synthesis
HTTP server allowed two simultaneous sessions with the same client, with
interesting effects. In SyncEvolution, the whole server only allows one
session at a time at the moment, to avoid such issues a priori.

--

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
Permalink | Reply | 8 comments |
headers
Patrick Ohly | 1 Oct 2009 15:58
Picon
Favicon
Gravatar

Re: libsynthesis_srv

On Fri, 2009-09-25 at 17:30 +0100, Lukas Zeller wrote:
> On Sep 25, 2009, at 16:29 , Patrick Ohly wrote:
> > Profiles are gone in the server. How do I control the sync modes  
> > used by
> > the server for specific datastores? I'm using
> >    <plugin_module>[SDK_textdb]</plugin_module>
> >    <plugin_sessionauth>yes</plugin_sessionauth>
> >    <plugin_deviceadmin>yes</plugin_deviceadmin>
> > for the server and my own plugin for each datastore.
> 
> The client controls the sync modes. The server just executes what the  
> client wants.

There may be cases where our datastore cannot execute an incremental
sync. What is the best way to force a slow sync? Erasing the admin data
(possible now that it is under our control)?

> > A related question: I was using the "dbname" in a target to find the
> > datastore name related to a progress event. The code looked like this
> > (with wrapper classes around the underlying handles):
> >       SharedKey targets = m_engine.OpenKeyByPath(profile, "targets");
> >       SharedKey target;
> >       target = m_engine.OpenSubkey(targets, progressInfo.targetID);
> >       std::string name = m_engine.GetStrValue(target, "dbname");
> >
> > Is there a better way that works in both client and server?
> 
> Note that the server does not have progress events at this time at  
> all. Could be added, but requires some work, and would require to re- 
> architect the progress events to some degree as these are all global
(Continue reading)

Permalink | Reply | 5 comments |
headers
Beat Forster | 1 Oct 2009 16:05
Picon
Favicon

Re: libsynthesis_srv

Hi Patrick

>  > To make sure that I understand you correctly:
>>  - You're using "server:" as a keyword to be parsed out as server flag.
>>  - In case of built-in, the flag will be used to change the entry point name
>>     ("SySync_srv_ConnectEngine"/"SySync_srv_DisconnectEngine")
>
>Correct. This will be necessary in particular once Lukas merges both
>versions of the engine into the same library.
Ok, clear.

>
>>  - In case of a library, the flag will be used to change the library name,
>>     BUT ALSO the entry point name to have it consistent for both cases.
>
>In case of a library the app still chooses the name itself. Only the
>entry point is affected.
We don't have a released server lib until today. 
So we can still decide how to do it. So I would 
propose to use the "srv" prefix for .a and .so. 
The search mechanism should still be for both 
SySync_srv_ and srv_.

>
>>  Yes, it would nice if you come up with a patch proposal.
>>  If I understand your proposal correctly, you plan
>>  to adapt the sources at UI_Connect/UI_Disconnect
>>  at UI_util.cpp only for this ?
>
>That, and the corresponding calls in enginemodulebridge.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Patrick Ohly | 1 Oct 2009 16:07
Picon
Favicon
Gravatar

Re: Server Alerted Notification (SAN)

Hello!

A friendly reminder: the question below are still open and relevant ;-)

In addition I'd appreciate some feedback from Beat on moving the SAN
class into the SDK - see the "san" branch in moblin.org.

Thanks, Patrick

On Thu, 2009-09-24 at 09:27 +0100, Patrick Ohly wrote:
> On Wed, 2009-09-23 at 17:34 +0200, Patrick Ohly wrote:
> > On Mon, 2009-09-21 at 16:31 +0100, Lukas Zeller wrote:
> > > I also attached a PDF (Synthesis_SyncML_SAN_implementation_notes.pdf)  
> > > which documents the way we have implemented SAN in the Synthesis PDA  
> > > clients (Winmobile and PalmOS). It might answer some of the questions  
> > > already.
> > 
> > Yes, it does, at least for the HTTP server case.
> 
> Some more questions...
> 
> First, the SyncML server may choose a Session ID in one of the SAN
> fields. If it does, the client is expected to use that in its first
> SyncML message. Is this supported by the Synthesis engine when running
> as client?
> 
> Second, when using the Synthesis server to synchronize against phones
> via Bluetooth we will have to emulate other servers ("PC Suite") and
> their URIs, otherwise the phones won't know how to sync with us. We
> don't want to name our server datastores according to what some other
(Continue reading)

Permalink | Reply | 11 comments |
headers
Patrick Ohly | 1 Oct 2009 16:28
Picon
Favicon
Gravatar

Re: libsynthesis_srv

On Thu, 2009-10-01 at 15:05 +0100, Beat Forster wrote:
> Hi Patrick
> 
> >  > To make sure that I understand you correctly:
> >>  - In case of a library, the flag will be used to change the library name,
> >>     BUT ALSO the entry point name to have it consistent for both cases.
> >
> >In case of a library the app still chooses the name itself. Only the
> >entry point is affected.
> We don't have a released server lib until today. 
> So we can still decide how to do it. So I would 
> propose to use the "srv" prefix for .a and .so. 

Yes, we can still change this. I don't care either way.

> The search mechanism should still be for both 
> SySync_srv_ and srv_.

Just to avoid confusion: you agree that the SDK should not care about
the naming of the module that it loads?

> >>  Yes, it would nice if you come up with a patch proposal.
> >>  If I understand your proposal correctly, you plan
> >>  to adapt the sources at UI_Connect/UI_Disconnect
> >>  at UI_util.cpp only for this ?
> >
> >That, and the corresponding calls in enginemodulebridge.
> >I've pushed all of my changes into the "server" branch on moblin.org.
> What to be changed here ? The UI_Disconnect adaption ?
> For some reasons I've password problems for the git on the moblin server.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane