Patrick, Thanks for your guidance today. I got my branch uploaded to http://cgit.collabora.com/git/user/jwhiting/syncevolution.git/ it's the syncpbap branch. Currently it starts the transfer and does work (I see vcard data in the file) however as you can probably see my SignalWatch understanding is not that great. I thought I could watch the transfer path, but apparently SignalWatch only works on a remote dbus object, not an object and path. I didn't quite follow what you were saying earlier about putting a watch on everything, how would that work (the signal is on the transfer path only, not the whole obex client object)?
thanks, Jeremy On Thu, Aug 23, 2012 at 9:26 AM, Patrick Ohly <[email protected]> wrote: > On Wed, 2012-08-22 at 15:43 -0600, Jeremy Whiting wrote: >> Patrick, >> >> Ok, I've taken your last comments into account, and also have a log >> with debugging turned on to try to figure out the gvariant error. As >> can be seen in the pbaplog.txt PullAll takes a string filename as >> argument, and returns an object and an a{sv} of properties, so where >> is the gvariant error in the dbuscallback coming from? > > Got it. What it returns is not a sequence of object path followed by the > dict, which would be "oa{sv}". Instead it returns a tuple containing > those two values: "(oa{sv})". > > That difference is probably irrelevant in a Python client which will > just convert whatever it gets and then store that in a loosely typed > variable, which happens to be a tuple in both cases. > > The demarshal code for GDBusCXX::DBusClientCall is a bit more picky and > expects something which matches exactly what was declared. > > The following code works: > > GDBusCXX::DBusClientCall1< std::pair<GDBusCXX::DBusObject_t, Params> > > pullall(*m_session, "PullAll"); > std::pair<GDBusCXX::DBusObject_t, Params> transfer = > pullall(std::string("/tmp/temp.vcard")); > const GDBusCXX::DBusObject_t &path = transfer.first; > const Params &properties = transfer.second; > > SE_LOG_DEBUG(NULL, NULL, "pullall transfer path %s, %ld properties", > path.c_str(), (long)properties.size()); > > You patch didn't apply against the current pbap branch, so I hacked the > current code myself. Diff is attached. > > Note that receiving a dict like that can fail: Params is only defined > such that the content of the boost::variant can be a std::string. If > obexd ever returns a different kind of value in its property dict, than > that value will cause a similar demarshalling error. > > Instead we need a boost::variant<std::string, GDBusCXX::DBusObject_t, > int, bool, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, > uint64_t> as value for the map. > > This will require some cut-and-paste work to extend > src/gdbusxx/gdbus-cxx-bridge.h such that "dbus_traits <boost::variant" > is available for up to 11 different types in the boost::variant. > > One more comment about your patch: is there a reason for switching to > the asynchronous method call approach? It's harder to read and has > issues that need to be dealt with, like no longer having a valid "this" > pointer when the call completes (which it will do, even if the calling > instance is long gone!). > > If you want to go down that road, bind a boost::weak_ptr for the > instance to be on the safe side instead of the plain pointer. Then > attempts to call the bound method will first lock the pointer and do > nothing when that is no longer possible. > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
