[Freeciv-Dev] Re: curiosity

[Andrew Sutton <ansutton@xxxxxxx>]

On Friday 30 November 2001 03:58 pm, Reinier Post wrote:
> As usual, I won't bring in much code, but I'll comment anyway ...
> wouldn't it be better to switch to C++ or even Java for 2.0?

ahhh... you speak my language :) C++ is probably a better solution for the 
server. a default client could be written using Qt. so, let's switch to c++ 
for version 2.0 - unless anybody can provide a solid reason why not (don't 
forget performance degradation is a myth).

> This seems The True Way Forward, but I don't think the existing
> codebase is a good basis; neither is a requirement for backward
> compatibility.  So why not switch to a more suitable language.

true. i was mostly speaking to the way problems had gone about being solved. 
not necessarily the codebase.

> > i'd also like to improve and generalize the network protocol to make it
> > something more like a traditional API instead of a series of sends and
> > gets.
>
> The asynchronous nature of the protocol is a design feature.
> It really helps on poor connections.

and it would remain. there seems to be an essential requirement that the 
protocol is bidirectional, a server both allowing requests and sending 
notifications. i just think it could be defined a little better.

the one thing i'd insist on, if we decide to go with c++, is the use of ACE 
(Adaptive Communication Environemnt) for the server. it provides a very, very 
graceful implementation of OO network programming.

> Do we have open solicitations for maintainership in this branch?
> Will there be a need to have this as a CVS branch, or will it use its
> own CVS server?

i don't know. it could probably use the same server and just reside in a 
different module. that might not be too bad. can we think of a list of jobs 
that people would need write access for?
        - cvs maintainer (maintains cvs as a whole)
        - build guru (ensures that the build is put together correctly)
        - kernel guru (responsible for kernel dev and patches)
                - ruleset parsing
                - network
        - owner for each module (responsbile for his/her module)
        - graphics maintainer
        - sounds maintainer
        - client guru
        - ai guru

that's at least 6 people with write access, plus one for every module. also, 
there should probably be a couple "trusted" developers under each subsection. 
each subsection should probably be able to maintain itself - maybe even 
schedule its own releases (in the case of modules) based on the current state 
of the kernel and the kernel interfaces.

it should be interesting to say the least :)

andy