http://bugzilla.moblin.org/show_bug.cgi?id=7700 pohly <patrick.ohly(a)intel.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |7713 -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #2 from pohly <patrick.ohly(a)intel.com&gt; 2009-11-16 00:53:19 PST --- (In reply to comment #1) No. The signal is sent to *D-Bus* clients, not peers connected via some kind of transport stub. The presence of peers only has to be detected if we can contact the peer (outgoing OBEX, HTTP). In other words, for the builtin-transports, but not for the transport stubs because those are for accepting connections. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #4 from pohly <patrick.ohly(a)intel.com&gt; 2009-11-16 02:48:55 PST --- (In reply to comment #3) Nothing specific has been decided yet. Previous discussions around "which process should be running permanently" pointed towards the syncevo-dbus-server as the most suitable candidate, in particular now that libsynthesis is only opened on demand (= lower memory footprint). I don't think obexd needs to be involved. In general, for Bluetooth peers we should either a) hook into the gnome-bluetooth package or b) wait for signals produced by it once the user has paired with a device. I don't know how that would work in practice. The open issues about this is bug #7089. Which httpd do you mean? syncevo-http-server.py? Because it never creates connections to a peer, it doesn't need to know anything about their presence. The Server.Attach/Detach mechanism is meant to be used for this. At the moment, if there is no client currently attached to the server, it doesn't have to poll. Automatic syncs will change that a bit. We'll probably need new configure parameters that control polling and things like "how long do we have to have a stable connection before we consider it good enough for a sync". Then we need to choose sensible defaults, because clearly, no Moblin user is ever going to set these values himself. Nothing? -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #6 from pohly <patrick.ohly(a)intel.com&gt; 2009-11-16 23:32:59 PST --- (In reply to comment #5) The transport mechanisms for outgoing connections are already part of the syncevo-dbus-server. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #8 from Chen Congwu <congwu.chen(a)intel.com&gt; 2010-01-10 23:25:14 PST --- (In reply to comment #7) Implementation for checkPresence may have some problems: During the dbus-call for checkPresence from clients, the dbus-server need to: call StartDiscovery(), waiting for any signals for DeviceFound within a certain period, finally decide whether the particular peer is reachable and reply to the client. Is this workable? Will the client timeout before dbus-server has actually finished the Bluez query? On the other hand, if the underlying Bluez discovery is always active, this will not be a problem; however I don't think this is perfect. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #10 from pohly <patrick.ohly(a)intel.com&gt; 2010-01-11 07:31:11 PST --- (In reply to comment #9) Jussi explained that "Bluetooth device paired" != "Bluetooth device available", which was my understanding so far. In that case we are screwed. We cannot determine reliably *and* cheaply whether a certain device is "present". I discussed this with Jussi and we agree that we fall back to "device is paired" as the definition of "present" for Bluetooth devices. If we do automatic syncs, we have to be aware that this is going to be costly for Bluetooth because it'll include trying to connect when the peer is not available. For configuration, our plan so far should work in the sense that it will only show devices which at least have a chance of getting used because they are paired. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #12 from Chen Congwu <congwu.chen(a)intel.com&gt; 2010-01-17 21:57:55 PST --- (In reply to comment #10) So we will not support "automatic sync" for Bluetooth devices. We will still detect basically: 1) The ethernet/wifi/wimax connection is present (hardware enabled, cable connected or AP connected) 2) The Bluetooth adapter is available (hardware enabled, we cannot detect further whether it is connected). In Moblin we will resolve to connman for all these work: org.moblin.connman Manager GetProperties() We will check (For HTTP, one of ethernet/wifi/wimax technology is enabled and connected; For Bluetooth, the Bluetooth technology is enabled.) In non-Moblin distributions, we may have to resolve to network manager for this work (not investigated in detail at this time). I will first come up with a Moblin solution. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #14 from pohly <patrick.ohly(a)intel.com&gt; 2010-01-19 04:44:16 PST --- (In reply to comment #13) I would keep it out of the transport agents, because we have more than one HTTP transport and only one HTTP presence module (which under the hood then checks two potential sources of information, conman and NetworkManager). But when would the transports have to check for presence? If they get created and are asked to contact someone, they should just go ahead and do that. They'll find out via errors that the peer is not present. The presence detection is for the higher levels in the stack, so that they can inform the user whether a sync might succeed. [D-Bus changes] Yes. As always, more issues may come up when actually adding code. I often find it useful to draft the class interfaces up in advance and call them in the rest of the code. That goes a long way towards ensuring that the APIs make sense. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #16 from Chen Congwu <congwu.chen(a)intel.com&gt; 2010-01-24 23:43:42 PST --- (In reply to comment #14) ether a sync might succeed. It now looks like this: In syncevo-dbus-server, I have to add a poll_nm event source that regularly query network manager/connman for network status. It is set up during construction of dbus-server and released until the server terminates. In poll_nm callback, it will create a DBus connection and call nm dbus apis via + typedef std::map <std::string, boost::variant <std::vector <std::string> > + DBusClientCall0<PropDict, DBusServer*, DBusServer> getProp (connman, "GetProperties"); + getProp (static_cast <DBusServer *> (dbusserver), &DBusServer::connman_cb); it also registered a callback (connman_cb in this case) expected be called after the dbus requests finished and results un-marshaled. The marshal and unmarshal dirty work are been done by DBusClientCall0 (which means 1 return value, no input argument), it looks like this: void operator () (A instance, Mptr C::*method){ //marshal input argument // call dbus_message_send_with_reply // set the callback to _callback // bind user supplied callback method to member function object _func } In _callback { //unmarshal return value from dbus message // call _func with the unmarshed return value which will route to user supplied callback method finally } Because connman.getProperties returned a dict with variant elements, I have to extend the dbus_traits to add another support for mapping dbus variant to boost::variant, it currently only supports one kind of variant (std::vector<std::string>): + * A boost::variant <V> maps to a dbus variant, only care about values of + * type V but will not throw error if type is not matched. + */ +template <class V> struct dbus_traits <boost::variant <V> > : public dbus_traits_base Is there any thing missing? I just got it compiled not debugged yet. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #18 from pohly <patrick.ohly(a)intel.com&gt; 2010-01-25 04:27:25 PST --- What will the internal structure in the syncevo-dbus-server be? Do you plan to add a structure of all configured peers that gets updated as the config changes and the peers change their state? Such a thing will be necessary for automatic syncs. The templates generated for present Bluetooth peers also need to live somewhere. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #20 from Chen Congwu <congwu.chen(a)intel.com&gt; 2010-01-25 20:22:52 PST --- (In reply to comment #18) As we currently only detecting whether the network is locally available, I actually don't have to store per-peer presence status, just 2 flags for HTTP and Bluetooth is enough. However for the long term solution, we definitely need such a structure for book keeping. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #22 from Chen Congwu <congwu.chen(a)intel.com&gt; 2010-01-28 21:56:13 PST --- 98f2557ac2add5bc34a14a2e5f209b48b9d3c50b Presence detection: connman part (MB#7700) This patch implements the presence detection dbus api (checkPresence and presence signal). It also takes account of the possiblity that a peer might have multiple contacting mechanisms (HTTP, Bluetooth..). It maintains a StatusMap, for each configured peer, a list of <transport, status> is recorded. The StatusMap will change either via Session.setConfig or network status changes, in both cases the presence signal will be sent out for each changed peers. CheckPresence API will return explictly about the presence status of a corresponding peer. Limitaions: The detection only detects local network adpater (wifi/ethernet connected or bluetooth adapter enabled). The detection works by regularly polling connman, however it should be improved by listening signals sending out by connman. The detection only queries connman, therefore on a distribution where connman is not available the peers will be always "presence". Here are some examples: Presence Signal: Funambl, "no transport", "http://my.funambol.com/sync" s, "no transport", "obex-bt://00:25:47:CB:E1:23" s, "", "obex-bt://00:25:47:CB:E1:23" Funambl, "", "http://my.funambol.com/sync" <arg type="s" name="transport"> <doc:doc> <doc:summary> If the server can be reached via multiple transports, this is the one which triggered the signal. Content of the string to be decided... </doc:summary> </doc:doc> </arg> My question is: if there are multiple transport changes at the same time (The case when the dbus server starts up), should I generate a signal for each transport(my current solution) or combine them together? CheckPresence: Funambol, "no transport", "" Funambol, "", "http://my.funambol.com/sync" Next I will try to write a unit test, it might take additional work because I have probably set up a "connman" service for test. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #24 from Chen Congwu <congwu.chen(a)intel.com&gt; 2010-02-01 23:33:51 PST --- (In reply to comment #23) No, it means the peer is in-contactable. I thought this is a wrong usage of the API, is it possible we will checkPresence a peer not yet configured? Apparently I made a mistake but it did compile... Please see the updated patches in presence branch -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #26 from Chen Congwu <congwu.chen(a)intel.com&gt; 2010-02-02 21:23:08 PST --- (In reply to comment #25) So return "no transport" for this kind of error usage is acceptable? Sorry, besides space before '{', is there any general formating comments you will suggest? Now I get your idea. The API was designed to accept a plain function pointer because I thought this is easier to use by the user(he doesn't need to know boost::function bind). Accepting a boost function as parameter simplifies the calling interface though. Agree. I don't quite get it. From the API it is the same with the existing code (EmitSignal for example), how could you make sure EmitSignal is worked with a long-lived instance while DBusClientCall0 is worked with a short-lived instance? And I also think if constructing DBusClientCall requires a reference for DBusCallObject, it should also implies DBusCallObject should be lived as long as DBusClientCall. Changing the API to pass a shared_ptr might works but not that simple: the API once requires a DBusCallObject and it is correct to pass a derived class ConnmanClient; however when changing to shared_ptr wrapper class, it no longer holds. I agree, this looks better. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #28 from Chen Congwu <congwu.chen(a)intel.com&gt; 2010-02-03 00:41:21 PST --- (In reply to comment #27) Right, when I try to interact with underlying C library call, the method name was changed to small_lower_case unintentionally... I would say ConnmanClient and DBusClientCall0 is created on the same function stack; therefore they are guaranteed to have the same life scope (The usage in the current code is safe, do you agree? Or did I missed something?) Yes, we can not prevent other users to use this API with risk but this is the same situation as EmitSignal. DBusCallObject only provides information about the sender of the dbus call (the interface name, the method name, etc.) The recipient of the call is a static function of DBusCallObject0, it does not rely on DBusCallObject0 instance. I prefer simply store the relevant information into DBusCallObject0 (still passing the reference but make a copy). -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 --- Comment #30 from Chen Congwu <congwu.chen(a)intel.com&gt; 2010-02-03 05:33:40 PST --- (In reply to comment #29) er, right. It's the recipient information held in DBusCallObject, however it is used during client call (the same behavior as the situation for EmitSignal call). Sorry, I must forgot to push the last change bits.. Updated. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=7700 Bug 7700 depends on bug 9435, which changed state. Bug 9435 Summary: The "Sync now" button is disabled: presence wrong, editing config must check presence http://bugzilla.moblin.org/show_bug.cgi?id=9435 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.