On 10/26/07, Christian Floerkemeier <[EMAIL PROTECTED]> wrote: > > We are just about to finalize the messaging framework of LTKJava and I was > wondering how the other LTK* libraries implemented the messaging. > > - Did you implement the request/response messaging, e.g. > ADD_ROSPEC/ADD_ROSPEC_RESPONSE, synchronously with the client blocking until > the reader fulfills the request? Or did you implement this asynchronously > via a callback/listener mechanism? > > - I guess you implemeted the listener mechanism anyway for messages > initiated by the reader such as READER_NOTIFICATION_EVENT, right? > > Don't think a common approach is necessary, am just curious. >
LTK-Perl exposes two action-packed high-level functions that are part of Link.pm. transact() monitor() transact() encodes a passed LTK-XML message to LLRP binary format, transmits it on the socket, and blocks synchronously waiting for the response monitor() simply blocks synchronously waiting for XPath expression match for any of a collection of XPath expressions. That's how we wait for asynchronous events. So basically the answer is synchronous, always. You can think of it as an LTK-XML equivalent of Select. Note that both of these synchronous approaches use select() to implement optional "time fence" and "timeout" which may be supplied with every call. Time Fence is a point in time in the future at which the function will return whether or not it got what it was looking for. Timeout returns if there is a lull between messages of a certain length. We haven't had much call for callbacks, although you can associate a callback with each monitor() XPath string. My philosophy is not to force the user to create a separate thread of execution. If they really need another thread, then they have the option of running monitor() in a separate thread without much trouble. One way or another, the socket has to be owned by a single thread anyway. Except in certain cases (like state machine implementation) I'm not a big fan of organizing my code as callbacks since it tends to scatter the client code all around the module. Our purpose for LTK-Perl is to write automated regression tests. For tests, transparency of the code is the highest priority. You don't want to be confused about whether a problem is your overly complex multi-threaded test, or the Unit Under Test itself. Stimulus/response, stimulus/response, repeat... Like many things it depends on the application. For a GUI program folks might like for the events to be desynchronized to their message queue. With my synchronous approach, they would end up forced to create a separate thread which monitors the connection and posts to queue. With publish/subscribe and a separate thread for the network stuff, the client application could get away with just registering callbacks that post to message queue. HTH -- John. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
