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
