On Tue, Nov 11, 2008 at 2:38 PM, Pep Ribal wrote:
> I don't think the MP servers have to change their philosophy. I don't think
> both networks should be merged: it would be better to have the possibility
> to choose. All this is a personal opinion, but I think your MP should
> remain
> intact, with the same philosophy, and just add into IVAO the ability to
> accept FG connections. You can't lose your identity, you should just gain
> the possibility to connect your simulator to the network of your choice
> based on which philosophy best suits you.
Hi Pep,
I don't know if this idea has been proposed yet....
FlightGear's multiplayer protocol is published and open. It is also
flexible in the sense that we can update or enhance the protocol if we have
good reason to do so. (Maybe to add a new feature or data field that is
helpful for talking to IVAO networks ... such as a secure open
authentication scheme.)
The IVAO team could implement a FlightGear compatible interface into their
network. The work would be done on their servers, but then nothing would
need to change on the FlightGear side. The IVAO team would not need to
expose their proprietary communication protocols, but instead would create
an implementaion of our open protocols at their side to accept FlightGear
connections. They could create their own proprietary interface to our
protocol as long as they don't grab any of our code to do so (or maybe the
developers that create the flightgear multiplayer system might consider some
special license grant to IVAO of at least critical structures in order to
make their job easier???) For example, I put the FGNetFDM structure
definition in the public domain to facilitate building communication links
with proprietary software (matlab for instance.) I designed the FGNetFDM
structure so I felt it was my right to do so, and I don't think it has hurt
us in anyway.
Of course the IVAO folks might be quick to point out that this would expose
an open-protocol route into the IVAO networks which is true, but it is
completely under their control, so if some day it does become a wide spread
problem, they could turn off flightgear access. And they would be able to
turn off access from specific ip address or specific subnets or ban specific
users. With the help of the smart flightgear developers, we could develop a
robust/secure open authentication/communication protocol, and perhaps they
could take the lessons learned there and apply them to their wider
proprietary network so that they don't need to depend on the shakey concept
of security through obscurity.
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
