From: Toby C. <tco...@di...> - 2004-10-12 22:37:41
|
Hi all, Where are we at in considering these changes or some sort of alternative, it is functionality that I am very keen on seeing in player.... Toby Toby Collett wrote: > Hi, > I considered the geometry style device interface, however while this > has some benefits it also has some drawbacks, namely you need to > define twice (or three times) as many interfaces, eg laser laser_geom > and laser_config, which adds a lot of complexity, not to mention > supporting this many interfaces... > The other drawback of geometry push through a data type interface, > partiularly in a PUSH_ALL mode is that config and geometry updates > will generally be at a much lower frequency to data updates, although > this isnt nesasarily a big problem... > > Maybe the alternative I mentioned of a variable content data packet is > the best bet, add 2 bit flags for wether the packet contains geometry > or config info and stick them on the end if it does...this would have > the advantage of being fairly transparent to devices that dont wnat to > support it (just ignore the bit fields)... but really it is fairly > similar to my original implementation... > > anyhow, just some more ideas, > Toby > > ahoward wrote: > >> Hi Toby, Brian: >> >> I havent looked at Toby's patch, but here are a few thoughts based on my >> incomplete understanding... >> >> The request/reply mechanism, while generally useful for doing device >> initialization, is hopeless for in-the-loop control (too slow, no PUSH >> mechanism). Your patch effectively addresses both problems by allowing >> each interace to support more than one kind of packet. This is >> something >> that we have been talking about for some time, but never implemented. >> >> With our recent changes to support multiple interfaces on each >> driver, we >> can now achieve the same effect using a separate interface: e.g., we >> could >> define a "geometry" interface which spits out data whenever the geometry >> of a device changes. If you dont care about the geometry, you dont >> subscribe to this interface. Dead easy to implement on the driver side; >> no changes on the client side. I suspect that this is what we should >> aim >> for in the next release. >> >> Coming back to the question of multiple packet types for each >> interface, I >> see both pros and cons in this. Pro is that you can keep data logically >> grouped in a single interface, con is the increased conceptial and >> programmatic complexity. Right now, I'm feel this would not be a good >> idea, but I could be persuaded. >> >> A. >> >> >> On Fri, 1 Oct 2004, Toby Collett wrote: >> >> >> >>> Hi Brian, >>> Just to clarify a little, the client doesnt actually recieve >>> unsolicited >>> response messages, I created two new messages types (for geometry and >>> config) which are passed as seperate messages rather than as response >>> messages, this makes it very easy for the client to just ignore these >>> messages if they are not wanted (which I have set up the c and c++ >>> client libraries to do). So the patch as it stands will only break >>> custom client libraries and these will be able to be fixed in about 3 >>> lines of code...the only issue then is a slight increase in network >>> traffic. >>> >>> I havent done this but in addition you could also add extra option for >>> the acess mode (binary ored for config/geom PUSH/PULL) and only push if >>> these are set, this would solve the network traffic issue. >>> >>> Feel free to take or leave which ever parts of the patch you like or >>> dont, if there is a better way to do this that you want me to look into >>> let me know, there is the option of having multiple types of data >>> packet(which could include geometry and config when needed), this would >>> probably require less server change but more client change so ...... >>> Toby >>> >>> Brian Gerkey wrote: >>> >>> >>> >>>> On Wed, 29 Sep 2004, Toby Collett wrote: >>>> >>>> >>>> >>>>> Attached is a fairly major patch to the player server (gzipped as I >>>>> wasnt sure about the attachment size limit) which allows for drivers >>>>> to push geometry and config changes to clients. This is useful when >>>>> a) you have a device whos geometry changes at runtime (ie the lower >>>>> sonar bank on the b21r) >>>>> b) you have two client subscribed to one device and one changes the >>>>> config, the changes can then be pushed to the other client (think >>>>> sick LMS resolution change) >>>>> c) im sure there are some other options, ... a device that changes >>>>> config automatically for power conditions... ? >>>>> >>>> >>>> hi Toby, >>>> >>>> Thanks for the patch. It's something that we've talked about for a >>>> long >>>> time, and would definitely be useful. Although, regarding your >>>> example >>>> (b), each laser data packet actually has enough metadata (resolutions, >>>> aperture) that it's self-contained; the client doesn't need to be >>>> separately informed about a configuration change. >>>> >>>> As you say, this is a major patch, since it changes the message >>>> protocol >>>> (i.e., a client may now receive unsolicited config responses). As >>>> such, >>>> it'll take me a while to look over your patch and decide how best to >>>> incorporate this functionality. >>>> >>>> brian. >>>> >>>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: IT Product Guide on >>> ITManagersJournal >>> Use IT products in your business? Tell us what you think of them. >>> Give us >>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >>> out more >>> http://productguide.itmanagersjournal.com/guidepromo.tmpl >>> _______________________________________________ >>> Playerstage-developers mailing list >>> Pla...@li... >>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>> >>> >> >> >> Andrew Howard email: ah...@po... >> Department of Computer Science http: >> www-robotics.usc.edu/~ahoward >> University of Southern California phone: 1 (213) 740 6416 >> Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 >> << Insert pithy saying here >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >> Use IT products in your business? Tell us what you think of them. >> Give us >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >> out more >> http://productguide.itmanagersjournal.com/guidepromo.tmpl >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> >> >> > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > |