[crossfire] C++/Qt server version

[Nicolas Weeger]

>   Seems like a sort of odd decision since most recent conversations have
> seemed to have decided that more content and less code work is what is
> really needed to be done, but this seems to be a big code project...

Yes, it has the potential to be ambitious.

>   And just given the size and changes of the project, I'd like to see more
> detailed information - this isn't a minor change being made here.

I plan on having design documents before coding, so hopefully we'll have time 
to think things over. So I can't give much details now, as I don't know them 
all :)
Is that a satisfactory anwser? :)

>   I also wonder that given such a rewrite if maybe a more drastic approach
> is needed.  IMO, one reason for the messy/bad code is to maintain
> compatibility - new things are added, but don't want to break old
> maps/archetypes/whatever.  I think some things could be simplified a great
> deal (or made more efficient) if it was considered OK to break some of that
> compatibility - this may mean lots of maps need updating, but if you're
> going to do a major rewrite, it may be an overall plus just to give up on
> some of that compatility for clean code.

Indeed, but then let's do the whole thing and convert *ALL* things. One of the 
reasons for the mess is that people (me included, quite certainly) don't do 
the conversion globally, and only change a few maps/archs, thus we need to 
keep old compatibility code.

>   I do remember a long time ago someone else looked at doing crossfire in
> C++, and his decision was basically to do it from scratch - better to write
> something that meets the functional spec than to try and figure out what
> all that code does, etc.  But that is clearly a larger project.  A plus is
> that with a complete re-write, one could at least architect it for certain
> things.  But then you start asking questions on what is crossfire really,
> etc.

As Yann mentioned in another mail, rewriting from the ground up with copy / 
paste can be a solution.

>   I think it sort of depends on the expected development model.  But I'd
> generally say do it as a branch.
>
>   If individual changes were limited in scope to a few files and were
> basically complete at each commit, then maybe working directly in trunk
> would be OK.  But changing languages would seem that that is less likely
> case.  .
>
>   The flip side is also that if not many changes are being made in the
> trunk, it should generally be fairly easy to keep up to sync (there aren't
> changes be made that requires syncing up, etc)

I think it'll be on a branch, yes.

>   I do have some concerns like Kevin's, in that the rewrite could take a
> long time (I have no idea on your expected schedule on this, so maybe not).
>  I'd actually be more concerned that the trunk gets left in some hybrid
> state - some stuff rewritten, some stuff not, and unclear if having 30% of
> it rewritten in C++/Qt and rest be old C is better than 100% in old C.

Doesn't matter. Current C code builds in C++ easily, so no "is that C or C++?" 
philosophical question :)
(and that's not a theoritical reply, I did test a few months ago - code didn't 
change enough to warrant another test)


Nicolas
-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081124/e96d3842/attachment.pgp