Thread: [Opensync-devel] Main sink connecting

Status: Beta

Brought to you by: azrael2, dfriedrich, dgollub_

opensync-devel

[Opensync-devel] Main sink connecting

From: Paul E. <blu...@bl...> - 2009-09-27 10:42:32

Hi all,

I've just recently changed opie-sync to do the connection to the device in a 
main sink rather than checking if it needed to be done within each objtype 
sink. However I have come accross some behaviour that I don't understand. It 
seems the main sink only connects after all of the objtype sinks have 
connected. In my case I need to connect to the device, and then after that I 
need to determine for each objtype whether slow-sync is required; this latter 
task needs to be done at the connect stage I believe. I don't think the way it 
works now will let me do that without going back to having the main connect 
logic in each objtype sink's connect function; but if I do go back I can't 
retrieve a few stored values that I am (at the moment) putting into the main 
sink's state db.

I assume this connect order is intentional. If so, what is the reason for 
doing it this way?

Thanks,
Paul

[Opensync-devel] [RFC] Change order of main/objtype plugin-sink function calls? (was: Main sink connecting)

From: Daniel G. <go...@b1...> - 2009-10-10 13:19:15

Attachments: connect-sink-switched-order.diff

On Sunday 27 September 2009 12:22:00 pm Paul Eggleton wrote:
[...]
> I've just recently changed opie-sync to do the connection to the device in
>  a main sink rather than checking if it needed to be done within each
>  objtype sink. However I have come accross some behaviour that I don't
>  understand. It seems the main sink only connects after all of the objtype
>  sinks have connected.

Correct, main sink comes always after the objtype sinks. Not only for 
connect(-phase) ...

>  In my case I need to connect to the device, and then
>  after that I need to determine for each objtype whether slow-sync is
>  required; this latter task needs to be done at the connect stage I
>  believe.

Ah ok. I'm not quite sure yet if there would be any downside if we would 
change this to something like that:

Current Implementation:
-----------------------

1. Connect:
   1.1 ObjType Sink connect()
   1.2 Main Sink connect()

2. Connect Done:
   2.1 ObjType Sink connect_done()
   2.2 Main Sink connect_done()

3. Read (optional, only used if conflicts got ignored on a  previous sync)
   3.1 ObjType Sink Read ignored changes read()
  (3.2 Main Sink read ignored changes read()) FIXME: not implemented ... :/

4. Get Changes:
   4.1 ObjType Sink get_changes()
   4.2 Main Sink get_changes()

5. Commit:
   5.1 ObjType Sink write()
   5.2 Main Sink write()

6. Sync Done:
   6.1 ObjTYpe Sink sync_done()
   6.2 Main Sink sync_done()

7. Disconnect
   7.1 ObjType disconnect()
   7.2 Main Sink disconnect()

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

New Implementation (proposal):
-----------------------------

1. Connect:
   1.1 Main Sink connect()         <----- CHANGED
   1.2 ObjType Sink connect()      <----- CHANGED

2. Connect Done:
   2.1 Main Sink connect_done()    <----- CHANGED
   2.2 ObjType Sink connect_done() <----- CHANGED

3. Read (optional, only used if conflicts got ignored on a  previous sync)
   3.1 ObjType Sink Read ignored changes read()
  (3.2 Main Sink read ignored changes read()) FIXME: not implemented ... :/

4. Get Changes:
   4.1 ObjType Sink get_changes()
   4.2 Main Sink get_changes()

5. Commit:
   5.1 ObjType Sink write()
   5.2 Main Sink write()

6. Sync Done:
   6.1 ObjTYpe Sink sync_done()
   6.2 Main Sink sync_done()

7. Disconnect
   7.1 ObjType disconnect()
   7.2 Main Sink disconnect()

I quickly tested if i change the order only for the connect phase - the 
testsuite resutls looks pretty good:

http://opensync.org/testing/buildSummary.php?buildid=10940

The 4 tests which fail looks like only testcases which tried to verify the old 
order (1. main sink, 2. objtype sink ...) which just require quick adaption 
...

>  I don't think the way it works now will let me do that without
>  going back to having the main connect logic in each objtype sink's connect
>  function;

Ok, i see. This would be bad... so we should try to avoid this redudant 
connect implementaiton - right?

>  but if I do go back I can't retrieve a few stored values that I
>  am (at the moment) putting into the main sink's state db.

I see ...

> 
> I assume this connect order is intentional. If so, what is the reason for
> doing it this way?

I can't remember if there was any real intention doing this order .. so this 
was implemented this way by Armin before my time doing 0.3x development... 
currently i don't see any reason changing the order for connect. I would keep 
the 1. master, 2. objtype-sink order for disconnect ... 

All, anyone who would face issues changing the objtype-sink order for connect 
and connect_done? Would anyone see advantages changing the order for other 
plugin-sink functions?

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] [RFC] Change order of main/objtype plugin-sink function calls? (was: Main sink connecting)

From: Paul E. <blu...@bl...> - 2009-10-10 13:29:20

Hi Daniel,

On Sat, 10 Oct 2009, Daniel Gollub wrote:
> New Implementation (proposal):
> -----------------------------
> 
> 1. Connect:
>    1.1 Main Sink connect()         <----- CHANGED
>    1.2 ObjType Sink connect()      <----- CHANGED
> 
> 2. Connect Done:
>    2.1 Main Sink connect_done()    <----- CHANGED
>    2.2 ObjType Sink connect_done() <----- CHANGED

Changing the connect would be good for me obviously, but I'm not sure about 
connect_done - for my plugin I don't use it, so I'm not sure of its 
intended/current usage, but it's possible you may want the main sink to have 
the last "say" for this latter function.

I'll be interested to hear what the other plugin devs think about this.

Cheers,
Paul