[crossfire] C++/Qt server version

[Mark Wedel]

Nicolas Weeger wrote:
> Hello.
> 
> I do plan to have a C++/Qt (core only, no X dependency) version of the server, 
> with advanced stuff (dynamic archetype loading, ...).
> 
> I do expect / want this version to become the official server ("winning" on 
> features, hopefully :)).
> 
> But I definitely don't want a fork, so I'd like to work on CF's SVN server.

  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...

  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 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.

  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.


> 
> So two options:
> - I work directly on trunk - my preferred option, considering it's "unstable" 
> since some years, and doesn't seem to be soon stable, not much work going on 
> it

  unstable can have various meanings.  One could be it constantly crashes/is 
unreliable.  Another could be that that the interfaces/features are not fixed 
and can change with short notice.

  I'd consider the trunk in that second category - I don't think it cores all 
the time, but rather it was made unstable so changes could be made without 
worrying about breaking existing characters, etc.

> - I make a branch and work there - and if needed / when we want we merge to 
> trunk
> 
> Opinions?

  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 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.