|
From: Daniel G. <go...@b1...> - 2009-10-10 13:19:15
|
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 |