could HTTPhi helps connecting to VATSIM ?

[Michat]

Beeing HTTP a COM protocol, I wonder if does could help connecting to VATSIM.


Thanks for your analisys in advance.


Have a good Summer FG'ers.

[Hooray]

not any more, or less, than using any of the other I/O options - ultimately, you'd still need some kind of middleware to act as the "broker" between fgfs and ivao/vatsim.
Keep in mind that this is generally unrelated to Phi, the main thing that would be useful for such a setup, is the back-end used by Phi itself, i.e. mongoose and its XML/RPC layer to get/set properties and run fgcommands.

Thus, there is no immediate benefit in using Phi for this, unless the ATC-side happens to be a web-service, too.

[Michat]

I said Phi because it has instructor centre, it uses http(d) which I don't know if is the protocol to connect web-networks, and GUI. You can see that I'm not and expert.

There is a real demand in FG for Vatsim, initially based on the FG info , it hurts to see our very well prepared pilots using other SIMS in order to satisfy their connections to.

middleware to act as the "broker"

this sound like a risky business. Do you know roughly in what it's consist off, if trading, leverage, external relations, money, request-autorizations, or instead off is doable by our side code independently?

Any light?

Cheers.

[Hooray]

I suggest that you search the archives for "VATSIM", "IVATO" and "virtual ATC", you will be able to find many topics discussing the details and challenges (think NDAs), as well as existing workarounds. You will end up with a much better understanding of the situation

For starters, you could check these:
http://wiki.flightgear.org/FlightGear_N ... ghtGear.21
http://wiki.flightgear.org/SquawkGear


There also is a tonne of information, and pointers, archived at: http://wiki.flightgear.org/Stand_Alone_ ... evelopment

In summary, the middleware approach makes the most sense of all ideas - e.g. by customizing/extending the fgms code and using that to provide all the data.

[Michat]

Thank you hooray.

[Hooray]

Note that Phi itself is basically irrelevant in terms of middleware, because Phi is "just" what your browser is processing/rendering, i.e. the HTML/JavaScript part of the equation, its back-end is using a httpd server (mongoose) and a few custom I/O options using web sockets to expose the property/fgcommand interface to Phi.
Thus, Phi itself has really no relevance at all in the context of acting as some kind of broker/middleware with other software, regardless of it having an instructor station or not - ultimately, you need ATC-enabled fgfs instances to "connect" to some kind of server/middleware to act as the broker between FlightGear pilots and the virtual ATC environment.

For the time being, the most likely candidates for doing this sort of thing are the multiplayer environment (fgms specifically), and/or a middleware approach using existing I/O means (think telnet/props or a custom protocol), or even HLA/DIS.

In general, the only relevant Phi-related component is the mongoose/web socket layer exposing fgcommands and properties - however, you would typically not use this to exchange data with other fgfs instances without using a middleware, or you'd literally need to set up an authentication scheme and expose your IP address/port number - so it's hard to come up with a Phi related scenario that is not conceptually wrong.

You are into texturing and using Photoshop/GIMP, right ?
In layman's terms: Phi is kind of the final "output" (think texture), whereas you need access to the internals of the application (think GIMP), so that what you really need is some kind of "plugin" mechanism - and absent that, you need to use another application (middleware) to use existing protocols to obtain/exchange the relevant information from FlightGear