Re: [Flightgear-devel] Exposing a property over MP
Hi, On Thursday 08 October 2009 17:29:21 James Turner wrote: Related to the new route-manager: I could very easily define a string property which contains a plain text summary of the filed flight-plan. What is the magic required to expose that string (which be 200 or 400 bytes, I guess, depending on how many waypoints are in the route) over MP, so that the ATC 'aircraft' could see them? Is there an 'event' channel in MP, to deal with properties which change infrequently? (Compared to position/velocity/surface positions/ etc) No, the current implementation just dumps all. If you want to do that in a reliable way with a minimum of transferred data you will need a bunch of changes to the protocol and the server. The easiest way would be to have some fields not updated on each cycle but just update only about every few seconds. Make sure that you add some randomness to the count that we avoid bursts to the communication of those values. Greetings Mathias -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
Hi, On Thursday 08 October 2009 22:09:40 Martin Spott wrote: If bandwidth is not a matter, then you'd probably want to jump on the HLA train and join the CERTI/VirtualAir effort. They're offering everything like subscribing to attributes and the such yet I have to state that reduced bandwidth footprint, compared to the current state, would be beneficial to have in CERTI ;-) ... currently working on fixing usability stuff in certi. So stay tuned :) Anyway, I also consider an RTI a possible multiplayer replacement. Even if we would handle local RTI federations different than internet wide stuff. But yes, an RTI provides almost all we would need to get that right. Greetings Mathias -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On Friday 09 October 2009 00:21:11 James Turner wrote: On 8 Oct 2009, at 23:05, Vivian Meazza wrote: This, or something very like it, is a long outstanding proposal that never quite made it. No one got a round tuit for it I guess. That said, a minute delay on event-driven properties is probably too much. Well if it's 30 seconds, I think a 30 seconds 'synchronising state with MP server' would be fine for most people - especially if it happens in parallel with scenery loading. If it's more like two minutes, then it certainly needs some thought, but I'd rather have a slightly sub-optimal UX for this case, but support event-drive props. (Especially if I want to centralise ATIS / active runways / navaid idents in the future, as John Denker has suggested before) Another option is for the MP server to cache all the props from each client, and allow clients to request a 'burst' of the cached state right after they connect, but before the normal updates start. I don't know how the MP server-server tieing is implemented, but I suspect such a cache would also be valuable in proxying event-driven props between servers. I'm actually working on a new MP-protocol. But since fgms is a one-man-show and my spare time is very limit, progress is very slow. What I have done so far: - handle UDP-traffic as a stream. Every client maintaines a receive-queue and a send-queue. The overlying process (fgms,fgfs) can simply read or write from/to clients as if it is a standard stream. - The server maintains a list of clients. Every client has a property tree, filled with values read over MP-protocol - The data sent over MP-protocol is defined in a property-xml-file, with additional attributes defining when to send (on change, evertime, once) - authentication between client and server Currently I'm trying to get everything working. I therefor I have written a pseudo client, called mpdummy. The code is currently not fully functional, as it is work in progress. I try my best to write some documentation of the current state over this weekend and put the current development version of fgms into cvs (the code currently in fgms-cvs is very outdated). For the curious reader: You can find some information about the protocol and code under: http://fgms.sourceforge.net/protocol/ (library documentation) and http://fgms.sourceforge.net/protocol.php (description about the protocol) But keep in mind that this information is not cutting edge. Cheers, Oliver -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On 9 Oct 2009, at 07:30, Oliver Schroeder wrote: Currently I'm trying to get everything working. I therefor I have written a pseudo client, called mpdummy. The code is currently not fully functional, as it is work in progress. I try my best to write some documentation of the current state over this weekend and put the current development version of fgms into cvs (the code currently in fgms-cvs is very outdated). Sounds fantastic, let me know if you'd like comments on the code or help with testing. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
James Turner wrote: There's quite a lot of improvements that could be made to higher levels of MP, if arbitrary properties could be synchronised over MP :) I once played with the idea of assigning 32-bit id's to property names (and make the unique and consistent across clients) and a simple push and pull protocol. I never materialized though (although I did point out a link to the code when the MP discussion started). Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
Oliver Schroeder wrote: On Friday 09 October 2009 00:21:11 James Turner wrote: On 8 Oct 2009, at 23:05, Vivian Meazza wrote: This, or something very like it, is a long outstanding proposal that never quite made it. No one got a round tuit for it I guess. That said, a minute delay on event-driven properties is probably too much. Well if it's 30 seconds, I think a 30 seconds 'synchronising state with MP server' would be fine for most people - especially if it happens in parallel with scenery loading. If it's more like two minutes, then it certainly needs some thought, but I'd rather have a slightly sub-optimal UX for this case, but support event-drive props. (Especially if I want to centralise ATIS / active runways / navaid idents in the future, as John Denker has suggested before) Another option is for the MP server to cache all the props from each client, and allow clients to request a 'burst' of the cached state right after they connect, but before the normal updates start. I don't know how the MP server-server tieing is implemented, but I suspect such a cache would also be valuable in proxying event-driven props between servers. I'm actually working on a new MP-protocol. But since fgms is a one-man- show and my spare time is very limit, progress is very slow. What I have done so far: - handle UDP-traffic as a stream. Every client maintaines a receive-queue and a send-queue. The overlying process (fgms,fgfs) can simply read or write from/to clients as if it is a standard stream. - The server maintains a list of clients. Every client has a property tree, filled with values read over MP-protocol - The data sent over MP-protocol is defined in a property-xml-file, with additional attributes defining when to send (on change, evertime, once) - authentication between client and server Currently I'm trying to get everything working. I therefor I have written a pseudo client, called mpdummy. The code is currently not fully functional, as it is work in progress. I try my best to write some documentation of the current state over this weekend and put the current development version of fgms into cvs (the code currently in fgms-cvs is very outdated). For the curious reader: You can find some information about the protocol and code under: http://fgms.sourceforge.net/protocol/ (library documentation) and http://fgms.sourceforge.net/protocol.php (description about the protocol) But keep in mind that this information is not cutting edge. This all sounds very exciting. I'm usually available for testing (on Windows) - remember the hassle we had with linux/Windows and MP in the past? Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On Friday 09 October 2009 14:47:14 Vivian Meazza wrote: This all sounds very exciting. I'm usually available for testing (on Windows) - remember the hassle we had with linux/Windows and MP in the past? We will not get into such trouble again. But... ;) I have ripped all plib networking code from the multiplayer part and replaced the code by a new library (which will be shared between fgfs and fgms). We have to make sure, that this library works on all supported plattforms. As stated in my previous mail, I'll try to get the code into my cvs over the weekend and we can start test compiling on different plattforms. Cheers, Oliver -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
Erik Hofman wrote: I once played with the idea of assigning 32-bit id's to property names (and make the unique and consistent across clients) and a simple push and pull protocol. As an interesting side effect, assigning pre-defined ID's to every property would require all involved aircraft to comply with a common property-subset instead of everyone defining their favourite ones at will ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On Thu, 8 Oct 2009, James Turner wrote: Related to the new route-manager: I could very easily define a string property which contains a plain text summary of the filed flight-plan. What is the magic required to expose that string (which be 200 or 400 bytes, I guess, depending on how many waypoints are in the route) over MP, so that the ATC 'aircraft' could see them? The way the MP protocol is done now you really really do not want to do that by creating a new MP enabled string property and put the flight-plan in it. Not only is the string encoding horribly inefficient (a 32bit word per character) but it would also be sent in each and every packet. Is there an 'event' channel in MP, to deal with properties which change infrequently? (Compared to position/velocity/surface positions/ etc) No, there isn't but this might be time to create one. There is a rather complicated Nasal module for that kind of communication in Nasal/mp_broadcast.nas which utilizes a MP enabled string property (but send the relatively short empty string, , when nothing is going on. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On 8 Oct 2009, at 18:08, Anders Gidenstam wrote: The way the MP protocol is done now you really really do not want to do that by creating a new MP enabled string property and put the flight- plan in it. Not only is the string encoding horribly inefficient (a 32bit word per character) but it would also be sent in each and every packet. That sounds bad :) Is there an 'event' channel in MP, to deal with properties which change infrequently? (Compared to position/velocity/surface positions/ etc) No, there isn't but this might be time to create one. There is a rather complicated Nasal module for that kind of communication in Nasal/mp_broadcast.nas which utilizes a MP enabled string property (but send the relatively short empty string, , when nothing is going on. Eurgh, that sounds bad too. The 'usual' way to handle this would be to interleave the current update packets with 'event' packets, for properties that change more slowly. Using a sequence number for each event packet, and using the regular update packets to send the current sequence number, it's possible to make the event packet delivery reliable - without incurring the overhead (or complexity) of TCP. There's quite a lot of improvements that could be made to higher levels of MP, if arbitrary properties could be synchronised over MP :) Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
The way the MP protocol is done now you really really do not want to do that by creating a new MP enabled string property and put the flight-plan in it. Not only is the string encoding horribly inefficient (a 32bit word per character) but it would also be sent in each and every packet. Wow, that's really bad, why are strings being encoded with 32 bits per character exactly? --Jacob -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On Thu, 8 Oct 2009, James Turner wrote: That sounds bad :) It is, but in my experience there is no core developer feeling particularly responsible for the MP subsystem - most of the few patches that has been submitted in the past years have disappeared into the mailing list archive without (re)action. Eurgh, that sounds bad too. Well, it isn't ideal but it works for my purposes - without breaking MP compatibility and without me having to spend a large effort on developing something reasonable and more complete and then try for ages to get it committed to the code. These days I don't have time to do significant development, anyway, with work + commuting taking about 12 hours out of every day. The 'usual' way to handle this would be to interleave the current update packets with 'event' packets, for properties that change more slowly. Using a sequence number for each event packet, and using the regular update packets to send the current sequence number, it's possible to make the event packet delivery reliable - without incurring the overhead (or complexity) of TCP. Well, I would rather try to reduce what we send and mostly only send property values when they have changed. Currently every packet contains all (active) MP enabled properties - and many of them are constant or change very seldom. In that model a string property that rarely changes would not be a huge problem. Perhaps some type of publish-subscribe model could also be useful - so the receivers only receive the properties they care about (usually position and velocities and those driving external animations if within visual distance). Of course, this adds up to a rather sophisticated protocol so if some suitable existing middleware could be found that might be more preferable than trying to go our own way (certainly if one considers the current level of activity in this area:). There's quite a lot of improvements that could be made to higher levels of MP, if arbitrary properties could be synchronised over MP :) Yes, indeed. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
James Turner wrote: There's quite a lot of improvements that could be made to higher levels of MP, if arbitrary properties could be synchronised over MP :) As far as _I_ remember, the current state of the protocol was _not_ designed for having everyone dump arbitrary data to the crowd but instead to allow for synchronization of positions, velocities and accelerations at reduced latency even over low-bandwidth lines. The current MP protocol is probably not perfect, but I think it still does quite a good job at its intended purpose. I remember running MP over a 64 kBit's ISDN line at satisfactory performance. If bandwidth is not a matter, then you'd probably want to jump on the HLA train and join the CERTI/VirtualAir effort. They're offering everything like subscribing to attributes and the such yet I have to state that reduced bandwidth footprint, compared to the current state, would be beneficial to have in CERTI ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
Anders Gidenstam wrote On Thu, 8 Oct 2009, James Turner wrote: That sounds bad :) It is, but in my experience there is no core developer feeling particularly responsible for the MP subsystem - most of the few patches that has been submitted in the past years have disappeared into the mailing list archive without (re)action. Eurgh, that sounds bad too. Well, it isn't ideal but it works for my purposes - without breaking MP compatibility and without me having to spend a large effort on developing something reasonable and more complete and then try for ages to get it committed to the code. These days I don't have time to do significant development, anyway, with work + commuting taking about 12 hours out of every day. The 'usual' way to handle this would be to interleave the current update packets with 'event' packets, for properties that change more slowly. Using a sequence number for each event packet, and using the regular update packets to send the current sequence number, it's possible to make the event packet delivery reliable - without incurring the overhead (or complexity) of TCP. Well, I would rather try to reduce what we send and mostly only send property values when they have changed. Currently every packet contains all (active) MP enabled properties - and many of them are constant or change very seldom. In that model a string property that rarely changes would not be a huge problem. Perhaps some type of publish-subscribe model could also be useful - so the receivers only receive the properties they care about (usually position and velocities and those driving external animations if within visual distance). Of course, this adds up to a rather sophisticated protocol so if some suitable existing middleware could be found that might be more preferable than trying to go our own way (certainly if one considers the current level of activity in this area:). There's quite a lot of improvements that could be made to higher levels of MP, if arbitrary properties could be synchronised over MP :) Yes, indeed. Way back in the early iterations of MP we had 2 sorts of messages - those which were transmitted on every cycle, and those which were transmitted on change of data. The trouble with that is with clients joining and leaving, it is hard to ensure that the clients are up-to-date. So you need to re- transmit on clients joining, which means triggering the originating client etc. etc. I think for that reason it was abandoned. It's just easier and more reliable to transmit everything all the time. And actually, the end result in data transmitted terms turns out to be not that different. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On 8 Oct 2009, at 21:37, Vivian Meazza wrote: Way back in the early iterations of MP we had 2 sorts of messages - those which were transmitted on every cycle, and those which were transmitted on change of data. The trouble with that is with clients joining and leaving, it is hard to ensure that the clients are up-to-date. So you need to re- transmit on clients joining, which means triggering the originating client etc. etc. I think for that reason it was abandoned. It's just easier and more reliable to transmit everything all the time. And actually, the end result in data transmitted terms turns out to be not that different. Easier certainly - but I think that was a bad tradeoff in the longer term. Sure, new clients will need to do more synchronize state, but potentially a lot of infrequently changing data can be removed from the regular updates, making them smaller too - while allowing, as everyone seems to agree, richer and easier MP interaction. As simple as possible is a good motto, but the current system seems a bit too simple. Of course, it does work - and I've got enough other FG projects that someone else can worry about this, for the moment. I'd be happy to share what I know about mixed reliable/best-effort real time networking, but it's not exactly much :) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On Thu, 8 Oct 2009, Vivian Meazza wrote: Way back in the early iterations of MP we had 2 sorts of messages - those which were transmitted on every cycle, and those which were transmitted on change of data. The trouble with that is with clients joining and leaving, it is hard to ensure that the clients are up-to-date. So you need to re- transmit on clients joining, which means triggering the originating client etc. etc. I think for that reason it was abandoned. It's just easier and more reliable to transmit everything all the time. And actually, the end result in data transmitted terms turns out to be not that different. Yes, that is one issue. The approach I aimed for the last time I tried to mess with the MP subsystem was to send properties on change (perhaps repeated Y times) and every X seconds (to update newly joined users and cover lost packets). That seemed to be simple enough that it could even be backwards compatible - but unfortunately it caused occasional failures in the property interpolation code on the receiving side that I didn't manage to sort out. Going in that direction could be a feasible way to reduce the bandwidth consumption, though. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On 8 Oct 2009, at 21:54, Anders Gidenstam wrote: Going in that direction could be a feasible way to reduce the bandwidth consumption, though. One other observation - there's several unused SGProperty flags (besides ARCHIVABLE) - it might make sense to add a 'shared' or 'published' flag, to allow properties to opt-in to being sent this way. Then the MP code 'just' has to search the tree (or keep an index) of such properties, listen for changes to them, and re-send them at some low rate (maybe send one in each regular packet, so it might take a minute to receive them all...) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
James wrote -Original Message- From: James Turner [mailto:zakal...@mac.com] Sent: 08 October 2009 22:06 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Exposing a property over MP On 8 Oct 2009, at 21:54, Anders Gidenstam wrote: Going in that direction could be a feasible way to reduce the bandwidth consumption, though. One other observation - there's several unused SGProperty flags (besides ARCHIVABLE) - it might make sense to add a 'shared' or 'published' flag, to allow properties to opt-in to being sent this way. Then the MP code 'just' has to search the tree (or keep an index) of such properties, listen for changes to them, and re-send them at some low rate (maybe send one in each regular packet, so it might take a minute to receive them all...) This, or something very like it, is a long outstanding proposal that never quite made it. No one got a round tuit for it I guess. That said, a minute delay on event-driven properties is probably too much. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On 8 Oct 2009, at 23:05, Vivian Meazza wrote: This, or something very like it, is a long outstanding proposal that never quite made it. No one got a round tuit for it I guess. That said, a minute delay on event-driven properties is probably too much. Well if it's 30 seconds, I think a 30 seconds 'synchronising state with MP server' would be fine for most people - especially if it happens in parallel with scenery loading. If it's more like two minutes, then it certainly needs some thought, but I'd rather have a slightly sub-optimal UX for this case, but support event-drive props. (Especially if I want to centralise ATIS / active runways / navaid idents in the future, as John Denker has suggested before) Another option is for the MP server to cache all the props from each client, and allow clients to request a 'burst' of the cached state right after they connect, but before the normal updates start. I don't know how the MP server-server tieing is implemented, but I suspect such a cache would also be valuable in proxying event-driven props between servers. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
