Hi Forrest, > >> Yes. My proposed PBAP storage API follows this rule, but lacks the > >> method to unregister the operations. Will add it later. > > > > I put some prototype declarations into the obexd repository. The > > important part is that we have to do this in an async way. We can't > > block while retrieving the phonebook information. > > > > I'm implementing PBAP driver framework and a simple(or prototype) PBAP > driver based on your prototype declarations. Will add some extentions > to the prototype declarations if necessary. > To do that in an async way I think the basic idea is: > 1 when PBAP driver is loaded(or initialized), fork() is invoked to run > PBAP driver in child process NO WAY. No fork() and no threads. That is just not needed. You get the callback and then you just use phonebook_return(). Check the code that is actually in the repository. It needs a little bit more work to get the details right, but it works how it should be. Also we do have a phonebook_context that presents a lifetime of a transaction. It needs to be extended and used properly, but it is how this is done. Also the pull phonebook, pull vcard listing and pull vcard entry with one specific context can not run simultaneously. The will run after each if at all. So we init a context and then we destroy the context once we are done with it. In between we can use the any callback. > 2 the Unix domain socket is used to communicate between PBAP server > and PBAP driver; and PBAP server acts as client role at the one end of > socket, PBAP driver acts as server role at the other end of socket NO WAY. Come on. Don't try to make this more complicated. Think simple and I already put all the ground works into the repository. We just need to parse the OBEX request properly and return the result from the plugin. And remember that obexd is designed for embedded systems and every process that we have to run additionally costs us. Not to mention that we end up with crazy dependencies for boot. > 3 everytime a PBAP client connects to PBAP server(i.e. a OBEX session > is initiated), PBAP server initiates a session(or a socket) with PBAP > driver by invoking connect(). Then PBAP server sends subsequent PBAP > request(pullphonebook, pullvcardlisting, pullvcardentry) through this > socket; PBAP driver sends back the requested data through the socket > asyncronously. > Am I right? I'd like to first make the basic design ideas clear in > order to avoid the unnecessary misunderstanding or confusion before > starting to write the code. The basic design is already pushed into the repository. Including sample code for accessing the Evolution Data Server via the ebook plugin. Start looking at that code, because that is the way to go. No need for an over-complicated design. The whole code is only missing some minor pieces I didn't have time for over the weekend. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
