Main sink connecting

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

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: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          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

[connect-sink-switched-order.diff]

---

Index: opensync/engine/opensync_engine.c
===================================================================
--- opensync/engine/opensync_engine.c (revision 5866)
+++ opensync/engine/opensync_engine.c (working copy)
@@ -1789,7 +1789,15 @@
 
  switch (command->cmd) {
  case OSYNC_ENGINE_COMMAND_CONNECT:
+
+ /* Then we connect the main sinks */
+ for (o = engine->proxies; o; o = o->next) {
+ OSyncClientProxy *proxy = o->data;
+ if (!osync_client_proxy_connect(proxy, _osync_engine_connect_callback, engine, NULL, FALSE, &locerror))
+ goto error;
+ }
 
+
  /* We first tell all object engines to connect */
  for (o = engine->object_engines; o; o = o->next) {
  OSyncObjEngine *objengine = o->data;
@@ -1800,13 +1808,6 @@
  if (!osync_obj_engine_command(objengine, OSYNC_ENGINE_COMMAND_CONNECT, &locerror))
  goto error;
  }
-
- /* Then we connect the main sinks */
- for (o = engine->proxies; o; o = o->next) {
- OSyncClientProxy *proxy = o->data;
- if (!osync_client_proxy_connect(proxy, _osync_engine_connect_callback, engine, NULL, FALSE, &locerror))
- goto error;
- }
  break;
  case OSYNC_ENGINE_COMMAND_CONNECT_DONE:
  case OSYNC_ENGINE_COMMAND_READ:

---

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft]

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.
>>    
>  
Daniel 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
>
>  

If the point of this change is to let the main sink handle some device
initialization in connect, I think it makes more sense to also allow the
main sink handle device finalization in done, so I would think this
sequence makes more sense:

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

2. Connect Done:
   2.1 ObjType Sink connect_done() <----- FIFO
   2.2 Main Sink connect_done()    <----- MAIN SINK LAST

/Henrik



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

Hi all,

So, any further thoughts/objections on this one? If not, it would be nice to
get the change made (at least for the connect)

Cheers,
Paul

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Saturday 17 October 2009 05:52:22 pm Paul Eggleton wrote:
> Hi all,
>
> So, any further thoughts/objections on this one? If not, it would be nice
>  to get the change made (at least for the connect)
[...]

Did you try the proof of concept patch? Is your plugin working with this patch
as expected?

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft]

Hi,

I am sorry, but I do not think this is a question of whether the patch
works.

As far as I am concerned, the modified proposed sequence is the "right" one:

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

2. Connect Done:
   2.1 ObjType Sink connect_done() <----- FIFO
   2.2 Main Sink connect_done()    <----- MAIN SINK LAST


If everyone agrees that this is "conceptually" the right thing to do,
it should be implemented in OpenSync, and if plugins need to be adjusted,
so be it.

/Henrik


Daniel Gollub wrote:

> On Saturday 17 October 2009 05:52:22 pm Paul Eggleton wrote:
>  
>> Hi all,
>>
>> So, any further thoughts/objections on this one? If not, it would be nice
>>  to get the change made (at least for the connect)
>>    
> [...]
>
> Did you try the proof of concept patch? Is your plugin working with this patch
> as expected?
>
> Best Regards,
> Daniel
>
>  

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

On Sat, 17 Oct 2009, Henrik /KaarPoSoft wrote:

> As far as I am concerned, the modified proposed sequence is the "right"
>  one:
>
> 1. Connect:
>    1.1 Main Sink connect()         <----- AS PROPOSED
>    1.2 ObjType Sink connect()      <----- AS PROPOSED
>
> 2. Connect Done:
>    2.1 ObjType Sink connect_done() <----- FIFO
>    2.2 Main Sink connect_done()    <----- MAIN SINK LAST
>
>
> If everyone agrees that this is "conceptually" the right thing to do,
> it should be implemented in OpenSync, and if plugins need to be adjusted,
> so be it.

Agreed, this makes sense.

FWIW, the patch does work for me though.

Cheers,
Paul

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel