headers
Patrick Ohly | 1 Feb 2012 16:03
Picon
Favicon
Gravatar

Re: [REVIEW REQUEST 0/7] PBAP backend proposal

On Di, 2012-01-31 at 14:34 +0100, Mikel Astiz wrote:
> Hi Patrick,
> 
> On 01/31/2012 08:38 AM, Patrick Ohly wrote:
> > I'm currently thinking about that myself. There are other use-cases for
> > it, for example the issue with the SyncML client side detecting that it
> > has more changes pending at the end of the normal sync. I'm leaning to
> > extend the internal SyncML session so that both sides just enter further
> > send/receive cycles until no further changes need to be transmitted.
> 
> That seems very interesting indeed for our use-cases. In this case the 
> requirement would be that the backend is able to keep some context 
> (session) from one pass to the next.

The goal is to only instantiate the SyncSource once. Any context (like a
handle for the current PBAP session) can be kept attached to it and then
be reused for multiple beginSync()+read/writeItems()+endSync() cycles.
The SyncSource must be prepared for this change of semantic and update
the changes that it reports when beginSync() is called again.

I've done some experiments with the Synthesis engine and got to a state
where more than one internal sync session was possible using the same
engine and source instances. Because the source wasn't prepared for it,
the second sync session promptly deleted all data... ;-)

It's still a pretty big hack at the moment, but I am confident that it
can be made to work without breaking anything else. I have to put it
aside now, though, and do some other work first - like preparing my
presentation for FOSDEM. You are not going to be there by any chance?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mikel Astiz | 2 Feb 2012 15:39
Picon

Re: [REVIEW REQUEST 0/7] PBAP backend proposal

Hi Patrick,

On 02/01/2012 04:03 PM, Patrick Ohly wrote:
> On Di, 2012-01-31 at 14:34 +0100, Mikel Astiz wrote:
>> Hi Patrick,
>>
>> On 01/31/2012 08:38 AM, Patrick Ohly wrote:
>>> I'm currently thinking about that myself. There are other use-cases for
>>> it, for example the issue with the SyncML client side detecting that it
>>> has more changes pending at the end of the normal sync. I'm leaning to
>>> extend the internal SyncML session so that both sides just enter further
>>> send/receive cycles until no further changes need to be transmitted.
>> That seems very interesting indeed for our use-cases. In this case the
>> requirement would be that the backend is able to keep some context
>> (session) from one pass to the next.
> The goal is to only instantiate the SyncSource once. Any context (like a
> handle for the current PBAP session) can be kept attached to it and then
> be reused for multiple beginSync()+read/writeItems()+endSync() cycles.
> The SyncSource must be prepared for this change of semantic and update
> the changes that it reports when beginSync() is called again.
>
> I've done some experiments with the Synthesis engine and got to a state
> where more than one internal sync session was possible using the same
> engine and source instances. Because the source wasn't prepared for it,
> the second sync session promptly deleted all data... ;-)

To avoid breaking existing code, another approach could be that the 
syncsource interface is extended, with methods that report if there are 
pending passes for this source. That would hopefully avoid having to 
modify all existing source types. I'm not sure how this would fit into
(Continue reading)

Permalink | Reply | 1 comment |
headers
Patrick Ohly | 2 Feb 2012 15:52
Picon
Favicon
Gravatar

Re: [REVIEW REQUEST 0/7] PBAP backend proposal

On Do, 2012-02-02 at 15:39 +0100, Mikel Astiz wrote:
> On 02/01/2012 04:03 PM, Patrick Ohly wrote:
> > On Di, 2012-01-31 at 14:34 +0100, Mikel Astiz wrote:
> >> On 01/31/2012 08:38 AM, Patrick Ohly wrote:
> >>> I'm currently thinking about that myself. There are other use-cases for
> >>> it, for example the issue with the SyncML client side detecting that it
> >>> has more changes pending at the end of the normal sync. I'm leaning to
> >>> extend the internal SyncML session so that both sides just enter further
> >>> send/receive cycles until no further changes need to be transmitted.
> >> That seems very interesting indeed for our use-cases. In this case the
> >> requirement would be that the backend is able to keep some context
> >> (session) from one pass to the next.
> > The goal is to only instantiate the SyncSource once. Any context (like a
> > handle for the current PBAP session) can be kept attached to it and then
> > be reused for multiple beginSync()+read/writeItems()+endSync() cycles.
> > The SyncSource must be prepared for this change of semantic and update
> > the changes that it reports when beginSync() is called again.
> >
> > I've done some experiments with the Synthesis engine and got to a state
> > where more than one internal sync session was possible using the same
> > engine and source instances. Because the source wasn't prepared for it,
> > the second sync session promptly deleted all data... ;-)
> 
> To avoid breaking existing code, another approach could be that the 
> syncsource interface is extended, with methods that report if there are 
> pending passes for this source. That would hopefully avoid having to 
> modify all existing source types.

Absolutely. Part of the currently missing checks in the engine is
whether the source supports the extended behavior.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Kühl | 4 Feb 2012 12:32
Picon
Gravatar

DBus server rework: sync, shutdown, and password request

Hi Patrick,

This week I've been going down the path to get the password request
working. However, to get the session to even request a password we've
got to start a session which is one of the things I've been working
on.

One question I've got is when do we go about activating the sessions.
I'm assuming this can be done immediately. The approach I'm taking now
is to set the session 'active' and emit a status signal as soon as the
helper session's up and ready. Thus, the server creates a session and
it runs immediately.

I've also needed to look at how shutdown is handled in the course of
this. From what I can tell there are 2 events that can cause a
shutdown request: a signal or a file change. Because we are now
dealing with the ideal case that we have no queued sessions & multiple
sessions are running concurrently, it doesn't seem to me that we need
a ShutdownSession any longer. The shutdown session seemed to be used
to get to the head of the queue and prevent any new sessions from
starting. I'm going about removing that and just using the
m_shutdownRequested flag to disallow starting any additional sessions
etc.

Now for the actual infoRequest I'm doing the following. When the
request is made the helper emits a password request signal and waits.
The helper only does one job, so this is fine. The SessionResource in
the server receives this signal and creates an InfoRequest. Now we
can't wait in the server process because we've got possibly multiple
concurrent sessions running. So, I've introduced signal in InfoReq
(Continue reading)

Permalink | Reply | 38 comments |
headers
Patrick Ohly | 4 Feb 2012 14:45
Picon
Favicon
Gravatar

Re: DBus server rework: sync, shutdown, and password request

On Sat, 2012-02-04 at 12:32 +0100, Chris Kühl wrote:
> One question I've got is when do we go about activating the sessions.
> I'm assuming this can be done immediately. The approach I'm taking now
> is to set the session 'active' and emit a status signal as soon as the
> helper session's up and ready. Thus, the server creates a session and
> it runs immediately.

The 'active' state indicates that the session is allowed to be used for
operations. It doesn't guarantee that the session will react
immediately. So you could set it to active in the syncevo-dbus-server
side immediately, without waiting for the helper side to be ready. Is
that perhaps simpler?

> I've also needed to look at how shutdown is handled in the course of
> this. From what I can tell there are 2 events that can cause a
> shutdown request: a signal or a file change. Because we are now
> dealing with the ideal case that we have no queued sessions & multiple
> sessions are running concurrently,

You cannot guarantee that they are no queued sessions. A new session
might conflict with a running one and thus cannot start immediately.

>  it doesn't seem to me that we need
> a ShutdownSession any longer. The shutdown session seemed to be used
> to get to the head of the queue and prevent any new sessions from
> starting. I'm going about removing that and just using the
> m_shutdownRequested flag to disallow starting any additional sessions
> etc.

Do whatever works :-) The goal has to be that queued sessions are
(Continue reading)

Permalink | Reply | 37 comments |
headers
Tino Keitel | 4 Feb 2012 15:44
Picon

sync with remote syncevolution server fails

Hi,

I had to replace the SSL certificate on my syncevolution server, Now I
can't get the syncevolution client get to work anymore.

If I enter the URL in a web browser, I get a page with a "SyncEvolution
SyncML Server" text, so I assume the certificate stuff is correct.

This is logged on the server:

[INFO] syncevo-http: new SyncML session for 79.221.219.65
[ERROR] twisted: Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/twisted/protocols/basic.py",
line 239, in dataReceived
    return self.rawDataReceived(data)
  File "/usr/lib/python2.5/site-packages/twisted/web/http.py", line
1117, in rawDataReceived
    self.allContentReceived()
  File "/usr/lib/python2.5/site-packages/twisted/web/http.py", line
1108, in allContentReceived
    req.requestReceived(command, path, version)
  File "/usr/lib/python2.5/site-packages/twisted/web/http.py", line
626, in requestReceived
    self.process()
--- <exception caught here> ---
  File "/usr/lib/python2.5/site-packages/twisted/web/server.py", line
150, in process
    self.render(resrc)
  File "/usr/lib/python2.5/site-packages/twisted/web/server.py", line
(Continue reading)

Permalink | Reply | 3 comments |
headers
Patrick Ohly | 5 Feb 2012 11:17
Picon
Favicon
Gravatar

Re: Build failure on Ubuntu Precise Pangolin

On Sun, 2012-02-05 at 15:33 +0530, Rohan Garg wrote:
> Hi
> I tried to build SyncEvolution master on the current development
> version of Ubuntu and met with some compile errors as follows :
> 
> In file included from /usr/include/bluetooth/sdp.h:35:0,
>                  from ../syncevolution/src/syncevo/eds_abi_wrapper.h:67,
>                  from ../syncevolution/src/syncevo/SmartPtr.h:27,
>                  from ../syncevolution/src/syncevo/SoupTransportAgent.h:28,
>                  from ../syncevolution/src/syncevo/SoupTransportAgent.cpp:20:
> /usr/include/bluetooth/bluetooth.h: In function 'uint64_t bt_get_le64(void*)':
> /usr/include/bluetooth/bluetooth.h:131:9: error: invalid conversion
> from 'void*' to 'bt_get_le64(void*)::<anonymous struct>*'
> [-fpermissive]

This is a known bug in the new bluez header files:
http://thread.gmane.org/gmane.linux.bluez.kernel/20364

> Any pointers on how to fix the build would be appreciated since I'm
> not quite familiar with SyncEvolution internals.

There's no workaround in SyncEvolution. My hope still is that distros
will patch the Bluez header files.

If that hope turns out to be futile, then the easiest workaround might
be to copy the bluetooth.h header file at compile time before using it
and patching it locally - certainly not nice.

--

-- 
Best Regards, Patrick Ohly
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rohan Garg | 5 Feb 2012 11:03
Picon
Gravatar

Build failure on Ubuntu Precise Pangolin

Hi
I tried to build SyncEvolution master on the current development
version of Ubuntu and met with some compile errors as follows :

In file included from /usr/include/bluetooth/sdp.h:35:0,
                 from ../syncevolution/src/syncevo/eds_abi_wrapper.h:67,
                 from ../syncevolution/src/syncevo/SmartPtr.h:27,
                 from ../syncevolution/src/syncevo/SoupTransportAgent.h:28,
                 from ../syncevolution/src/syncevo/SoupTransportAgent.cpp:20:
/usr/include/bluetooth/bluetooth.h: In function 'uint64_t bt_get_le64(void*)':
/usr/include/bluetooth/bluetooth.h:131:9: error: invalid conversion
from 'void*' to 'bt_get_le64(void*)::<anonymous struct>*'
[-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function 'uint64_t bt_get_be64(void*)':
/usr/include/bluetooth/bluetooth.h:136:9: error: invalid conversion
from 'void*' to 'bt_get_be64(void*)::<anonymous struct>*'
[-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function 'uint32_t bt_get_le32(void*)':
/usr/include/bluetooth/bluetooth.h:141:9: error: invalid conversion
from 'void*' to 'bt_get_le32(void*)::<anonymous struct>*'
[-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function 'uint32_t bt_get_be32(void*)':
/usr/include/bluetooth/bluetooth.h:146:9: error: invalid conversion
from 'void*' to 'bt_get_be32(void*)::<anonymous struct>*'
[-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function 'uint16_t bt_get_le16(void*)':
/usr/include/bluetooth/bluetooth.h:151:9: error: invalid conversion
from 'void*' to 'bt_get_le16(void*)::<anonymous struct>*'
[-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function 'uint16_t bt_get_be16(void*)':
(Continue reading)

Permalink | Reply | 3 comments |
headers
Patrick Ohly | 5 Feb 2012 12:30
Picon
Favicon
Gravatar

Re: sync with remote syncevolution server fails

On Sat, 2012-02-04 at 15:44 +0100, Tino Keitel wrote:
> Hi,
> 
> I had to replace the SSL certificate on my syncevolution server, Now I
> can't get the syncevolution client get to work anymore.
>
> If I enter the URL in a web browser, I get a page with a "SyncEvolution
> SyncML Server" text, so I assume the certificate stuff is correct.
> 
> This is logged on the server:
> 
> [INFO] syncevo-http: new SyncML session for 79.221.219.65
> [ERROR] twisted: Unhandled Error
[...]
>   File "/home/scorpi/install/bin/syncevo-http-server_new.py", line 243,
> in render_POST
>     urlparse.urljoin(self.url.geturl(), request.path))
>   File "/home/scorpi/install/bin/syncevo-http-server_new.py", line 166,
> in start
>     self.object = Context.getDBusServer()
>   File "/home/scorpi/install/bin/syncevo-http-server_new.py", line 71,
> in getDBusServer
>     '/org/syncevolution/Server'),

It looks like it fails to find the syncevo-dbus-server on D-Bus.

Do you use a modified syncevo-http-server script (see _new.py suffix
above)? Just wondering.

> dbus.exceptions.DBusException:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frederik Elwert | 5 Feb 2012 13:01
Picon

Re: Build failure on Ubuntu Precise Pangolin

Am Sonntag, den 05.02.2012, 11:17 +0100 schrieb Patrick Ohly:
> On Sun, 2012-02-05 at 15:33 +0530, Rohan Garg wrote:
> > Hi
> > I tried to build SyncEvolution master on the current development
> > version of Ubuntu and met with some compile errors as follows :
> > 
> > In file included from /usr/include/bluetooth/sdp.h:35:0,
> >                  from ../syncevolution/src/syncevo/eds_abi_wrapper.h:67,
> >                  from ../syncevolution/src/syncevo/SmartPtr.h:27,
> >                  from ../syncevolution/src/syncevo/SoupTransportAgent.h:28,
> >                  from ../syncevolution/src/syncevo/SoupTransportAgent.cpp:20:
> > /usr/include/bluetooth/bluetooth.h: In function 'uint64_t bt_get_le64(void*)':
> > /usr/include/bluetooth/bluetooth.h:131:9: error: invalid conversion
> > from 'void*' to 'bt_get_le64(void*)::<anonymous struct>*'
> > [-fpermissive]
> 
> This is a known bug in the new bluez header files:
> http://thread.gmane.org/gmane.linux.bluez.kernel/20364
> 
> > Any pointers on how to fix the build would be appreciated since I'm
> > not quite familiar with SyncEvolution internals.
> 
> There's no workaround in SyncEvolution. My hope still is that distros
> will patch the Bluez header files.

Is there already a bug report for Ubuntu? There seem to be some issues
with bluetooth and I had the impression that some people are at least
looking into that. So it might be good to make them look into this issue
as well.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane