Re: [crossfire] C++/Qt server version
Hello. Reminder, the page http://wiki.metalforge.net/doku.php/dev%3Aserver_design and specifically the 'player-wise' section is waiting for you and your ideas! :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Hello. I've put a first basic draft at http://wiki.metalforge.net/doku.php/dev%3Aserver_design The first step, though, would be to define the exact kind of game we want, obviously :) Feel free to tweak the page and add stuff you think is missing! (note: the dates are informative, can be changed by some days/weeks if needed - but I don't expect those design steps to take years, actually) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Hello. Ok, from what I gather, people aren't against massive changes on the server. Reminder, though: content goes first, always :) So feel free to ignore all the technical aspects if you only want to make content :D So here is what we'll do: - put on a wiki page what kind of game we want (quick gameplay? slow combat? combat only? other things?), so we all know what we aim for - put on a wiki page features we want from a technical point of view - put down design ideas for those features - select which one we'll use - then decide whether to start from the current base, from scratch with copy'n'paste, what to use, and so on I guess I'm the one to start the wiki page, since I launched the discussion in the first place :) I shall do this soon, just a few things to think over before proposing things :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Le mardi 25 novembre 2008, Lalo Martins a écrit : quoth Lauwenmark Akkendrittae as of Mon, 24 Nov 2008 20:02:49 +0100: Le lundi 24 novembre 2008, Lalo Martins a écrit : I see two good reasons for Nicolas favouring Qt over Boost: - He's more familiar with Qt, and having to learn another toolkit, especially something as complex as Boost, would be somewhat of a waste of time; Agreed. - Although you mentioned several things that integrate nicely with Boost, providing Internationalization or a crossplatform building system, the whole point is that all of this is provided inside the Qt tool suite, and requires no external/3rd party dependency. This is a significant advantage to me. That's true for ICU, but not Jam; Jam *is* part of the Boost tool suite. True only if you were speaking of the Boost version of Jam. I had the Perforce version in mind, which is an independent tool. My own, personal tastes lean towards Qt more than Boost, mostly for the way Qt extended the C++ language to make some fundamental mechanisms more accessible. It provides a level of simplicity more in touch with the capabilities of my old braincells :). Hmm... the same could be said for Boost, Nope. I have worked (and still does) with Boost; it mostly builts upon existing language structures. From my personal experience (note the personal both here and my initial comment), Boost was not as easy to use as Qt. So yes, Boost provides an extensive, consistent library; yes, it allows using C++ in a very powerful way; no, it doesn't fundamentally make any of the language mechanisms simpler. and the improvements in Boost are more likely to be in future versions of the C++ standard, since there's a huge overlap in membership between the C++ committee and the Boost project. That's one of the main reasons I favour Boost. I don't see how what a future C++ standard may someday include would be of any relevance here. Being Qt or Boost, the code would still be C++ anyway. Also, here's something I forgot before: would use Qt imply using Trolltech's bastard C++ dialect, and MOC? There we hit your real issue, don't we? Short answer: yes, you have to use MOC, and yes, it implies using its language extensions. I see no point in commenting the bastard qualifier here - I care about the efficiency of a dialect, not about its possibly illegitimate origins. Or is that already dead and outdated? This simple question tends to demonstrate your quite superficial knowledge of Qt, else you wouldn't even have asked. Maybe you should evaluate both libraries before actually placing a judgement of their respective qualities/flaws ? If we'll have to code in a C++ dialect and require a toolset that not many people will already have installed, then I'm strongly opposed to Qt. The dialect point could indeed have been an issue - nobody wants to learn a variety of C++ just for a single project. But the changes are actually extremely limited - the most important being the addition of signal/slot mechanisms. It doesn't invalidate any of the existing C++ language definition. So far, I haven't seen many C++ coders complaining that the Qt Dialect was difficult to grasp. Regarding the toolset, I don't see where the problem is, since the required tools are shipped with the Qt SDK. Since the Boost libraries themselves are not installed by default on most platforms, I don't really get where the difference is. -- Lauwenmark. Drive defensively: buy a tank. signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
quoth Lauwenmark Akkendrittae as of Wed, 26 Nov 2008 17:18:45 +0100: Also, here's something I forgot before: would use Qt imply using Trolltech's bastard C++ dialect, and MOC? There we hit your real issue, don't we? Short answer: yes, you have to use MOC, and yes, it implies using its language extensions. I see no point in commenting the bastard qualifier here - I care about the efficiency of a dialect, not about its possibly illegitimate origins. Sorry, but I do care about its illegitimate origins, for the same reason that I care about future versions of C++. This project will probably take at least an year, more realistically three or four, to complete; it would be silly if in five years, or ten, it was already difficult to maintain due to tool/language obsolescence. Or is that already dead and outdated? This simple question tends to demonstrate your quite superficial knowledge of Qt, else you wouldn't even have asked. Maybe you should evaluate both libraries before actually placing a judgement of their respective qualities/flaws ? No, the word is not superficial, but outdated. I gave up on Qt years ago and haven't checked again (before even Qt3), one of the reasons being MOC. And I assumed there was a chance it would be gone by now, since IMO an idea so clearly idiotic as language extensions and pre-compiling couldn't stay around for too long in a library used by so many people. Apparently, I was wrong. Oh well. I'm now strongly opposed to using Qt. Strongly opposed as in: if Qt is chosen, I'll stop contributing, because I don't want to learn it. And I'll probably end up forking as well, if the uses I have in mind for the server require code changes. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Alex Schultz wrote: On Mon, 24 Nov 2008 22:06:40 -0800 Mark Wedel [EMAIL PROTECTED] wrote: Shared strings: While perhaps no reason to get rid of them, I also wonder how necessary they are now days. They do simplify comparisons. And with C++ and proper class descriptions, they can be made to be safe (have to use class functions to modify the name, and it knows to do the right thing). But shared strings date back a long time in crossfire, to when systems had much less memory and this wasmore a concern. They certainly do still save space, but the amount of space saved may not be worth the extra handling. It should certainly be reviewed - many design decisions date back to when computers where much less capable than they are now, and may not make much sense. I'm note sure exactly how much space is saved, but I think there's a high chance they may still be desirable due to the shear amount of floor tile objects and such in CF if someone is running through a large number of large maps. Now it's possible the benefit might be small these days but in any case, I don't think that making decisions about shared strings can go much further without getting real data on how much space they save. I looked on metalforge, and with the strings command, this is what came back: 3879 entries, 2476263 refs, 8196 links. So a good amount of space is being saved. But if we presume an average length of 10 for the strings, it amounts to 24 MB. The calculation is trickier - on the one side, there is overhead of the shared string structure itself in crossfire, but the counter is that if malloc is being used, it has some overhead of its own, so the difference there may not be that great. I suspect a much greater space savings may result in using C++ classes for objects, and allocating the type specific section of the object as needed. For example, for all those floor tiles, they really don't use much beyond the most basic fields of the object structure (name, x, y, etc). They don't need anything of the str, dex, hp fields, resistances, etc. So if objects were redone such that it was like 'oh, this is an equippable object - let me allocate the pointer for that', and 'oh, this is a floor object - nothing more is needed', one could get a pretty big space savings. Because of those 2476263 strings, probably almost every one of them is attached to some object. In fact, looking at metalforge, it looks like about 70 MB of space is used for objects. So C++ inheritance could save a lot of that space. snip Distributed server archetype: Need more details - having redundancy (client rerouting with minimal data loss) might not be worth the effort - have to make sure you don't have two servers trying to control the same area, recovery when one comes back on-line, etc. But being distributed (this server is responsible for scorn region, this one for navar city, etc) to reduce load may make sense, with there being smarts to transfer character detail between those, etc. In terms of server failure/crash, the client could improve that experience - most servers restart when they crash, so it is really to the client to pop up a window with something like 'connection lost - trying to reconnect (with spinning disk or something)'. Multithread server: I think this is a must - computers are moving more and more towards multiple cores, and less towards raw speed, and for crossfire to make use of those really requires multithreading. I always thought that multithreading at the map level would make the most sense - this potentially lets one use many threads (and thus cores) and is probably the simplest way to go. I was recently thinking about server multithreading, and now I'm thinking, why bother with threads? Why not do a model like one-process-per-every-few-maps instead of multithreading? It eliminates potential issues with mutexes and locking and such, transfering things between the processes could be done by IPC. The further advantage of going with a multi-process model instead of multi-thread model, is that much of the very same code could be adapted to make a distributed server possible if anyone ever thinks there's a need. I don't currently think there's a need for a distributed server system, but a multi-process model would lend well to adapting to distributed at a later date. Furthermore, a multi-process model would also make server crashes less disruptive because they'd usually just kill off a map or 3 instead of everywhere. Perhaps we should make a pros/cons chart to outline the merits of multi-process and multi-thread to compare? Maybe. Note that being able to run on a single box is a necessity, since that probably would be the way many folks run the system. note that processes tend to be a lot heavier than threads. And moving data back and forth is trickier. In a multithreaded model, you'd make a few locks, and could move the
Re: [crossfire] C++/Qt server version
On Tue, 25 Nov 2008 00:20:38 -0800 Mark Wedel [EMAIL PROTECTED] wrote: Also, I think re-joining existing servers may be more difficult. If I'm in scorn and go off into a new building, and that building is not currently active, it goes and forks off a new process and the existing file descriptor lives OK. However, if that building already has process associated with it (another player entered it), we can't fork - instead, my client has to get directed to that other process. And most likely, that means a different port (13329, 13330, ...) on that server. That is doable, but does require yet some other process to monitor all those forked processes out there to know what is available and what to connect to. Also, for folks running servers behind firewalls (probably most everyone) it means opening a potentially large number of ports. Well a few comments on these aspects. I don't think we need to mess around with opening more ports. One option is the supervising process could just proxy the connections through IPC. If this isn't good enough and we want direct connections to the process, it actually IS possible under both *nix and win32 to my understanding, to transfer file descriptors, and hence TCP/IP sockets, to another process, without disruption/disconnection/etc. This could also be used, so really, new ports or client changes would *not* be needed at all to support a multi-process model. (Note that all this said, I'm not current which approach I'd consider best, but I'm noting that one way or another, we wouldn't need additional ports or messing with the client or any of that kind of stuff, to achieve a multi-process model) Alex ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
quoth Lauwenmark Akkendrittae as of Mon, 24 Nov 2008 20:02:49 +0100: Le lundi 24 novembre 2008, Lalo Martins a écrit : I see two good reasons for Nicolas favouring Qt over Boost: - He's more familiar with Qt, and having to learn another toolkit, especially something as complex as Boost, would be somewhat of a waste of time; Agreed. - Although you mentioned several things that integrate nicely with Boost, providing Internationalization or a crossplatform building system, the whole point is that all of this is provided inside the Qt tool suite, and requires no external/3rd party dependency. This is a significant advantage to me. That's true for ICU, but not Jam; Jam *is* part of the Boost tool suite. My own, personal tastes lean towards Qt more than Boost, mostly for the way Qt extended the C++ language to make some fundamental mechanisms more accessible. It provides a level of simplicity more in touch with the capabilities of my old braincells :). Hmm... the same could be said for Boost, and the improvements in Boost are more likely to be in future versions of the C++ standard, since there's a huge overlap in membership between the C++ committee and the Boost project. That's one of the main reasons I favour Boost. Also, here's something I forgot before: would use Qt imply using Trolltech's bastard C++ dialect, and MOC? Or is that already dead and outdated? If we'll have to code in a C++ dialect and require a toolset that not many people will already have installed, then I'm strongly opposed to Qt. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
I have seen C++ messes that I would hate to see in CF, but then it is well known that you see current CF code as a mess in itself, so perhaps it has potential for cleaning up the code... Well, that is one of the points of the rewrite I'm proposing, indeed... I depend on trunk not being broken so that I can test and develop things on trunk. I no longer have interest in working on branch. I play only 2.x servers. I do not want trunk broken (for long periods) as that will only be a detriment to play testing and developing what is on trunk now. This is how I work on content - a topic on which you are most vociferous. Yes, I'm vociferous on content. It seems lately some moves are made in this field, so I'm trying to prepare the (bright !) future for the ambitious content people are thinking of :) (something that current CF code doesn't always enable us to write easily, IMO). But the (partial/full/total/global/[insert word]) rewrite I'm talking about is not immediately, it's in some months, after some design work and such. From the various points on this list, I think I'll work on a separate branch, so it's easier to work on content. (and as you I try to not work on branch/1.x anymore) While I recognize branching is a pain at times from my libglade effort in the client, it is my preference if I read your intentions correctly - it sounds basically like a huge rewrite. Whether the branch be of the whole project or only portions that will be broken for some time is not really a concern. Yup. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
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 !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Well, one thought, is there any reason Qt-core as opposed Boost C++ perhaps? If I understand correctly, they provide similar faculties but Boost C++ also provides some rather nice looking python bindings that may make it far easier to move cfpython to a C++ code style. I'm not saying anything is wrong with Qt-core, and I've never actually used it or Boost C++ for that matter, but I'm just wondering if should maybe be considered, as it may have merits. That said, as you're likely going to be the main person in this code effort, simply having more experience with QT-core than Boost C++ can be a significant and quite valid factor. I'm not a Boost specialist either (and that can have an impact on my preference for Qt), but from what I gather, here are Qt features Boost doesn't have (someone will correct me if I'm wrong): - multilanguage support - GUI classes - modular, so you can disable if not needed, and if you need you're using the same base classes - image manipulation - crossplatform build system Note that C++/Qt and Python interact decently with some tests, there doesn't seem to be any issue there. Not too much of a strong opinion, except that if you do work on trunk there should be either a tag or branch made for the current state of trunk. Yup. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
quoth Nicolas Weeger as of Mon, 24 Nov 2008 16:50:17 +0100: So why Qt: - cross-platform - well tested through KDE and many applications - has all the basics we need: strings (including shared strings for memory reduction unless I'm mistaking), sockets, file / directory, threads and locks, multilanguage support - modular so we can only use what we need (no GUI for server, definitely) - easy to plug in GUI if needed with class coherence - signal/slot mechanism that could be used for plugins or archetype reloading - existing unit test framework (not that advanced, but enough for almost all our needs I think) All your arguments are also true of Boost, thought ;-) with the added benefit (IMHO) that probably more people already have Boost installed than Qt. (Probably more people already know it, too.) Then again, as I said before, whatever you pick is fine... you're the one writing the code! best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Le lundi 24 novembre 2008, Alex Schultz a écrit : That said, a little searching shows that if we want similar automagical wrapping and go with Qt-core, apparently QtScript (an ECMAScript based scripting language which has been included in the Qt toolkit since 4.3.0), appears to be able to provide some kinds of similar things. Of course, it would also be plausible to use Qt-core for the bulk of the rewrite and Boost::Python for cfpython, but that could cause difficulties with differing string types and plain add redundant bloat to the dependencies. See http://pythonqt.sourceforge.net/ , which is a Python binding for QtScript. -- Lauwenmark. Drive defensively: buy a tank. signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Le lundi 24 novembre 2008, Lalo Martins a écrit : Before anyone gets the impression I'm turning this into a Boost holy war... let me reiterate I don't feel that strongly about it, just answering Nicolas' questions here. snip I see two good reasons for Nicolas favouring Qt over Boost: - He's more familiar with Qt, and having to learn another toolkit, especially something as complex as Boost, would be somewhat of a waste of time; - Although you mentioned several things that integrate nicely with Boost, providing Internationalization or a crossplatform building system, the whole point is that all of this is provided inside the Qt tool suite, and requires no external/3rd party dependency. This is a significant advantage to me. My own, personal tastes lean towards Qt more than Boost, mostly for the way Qt extended the C++ language to make some fundamental mechanisms more accessible. It provides a level of simplicity more in touch with the capabilities of my old braincells :). Just my 0.02€ :) -- Lauwenmark. Drive defensively: buy a tank. signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
On Mon, 17 Nov 2008 20:07:37 +0100 Nicolas Weeger [EMAIL PROTECTED] 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, ...). Well, one thought, is there any reason Qt-core as opposed Boost C++ perhaps? If I understand correctly, they provide similar faculties but Boost C++ also provides some rather nice looking python bindings that may make it far easier to move cfpython to a C++ code style. I'm not saying anything is wrong with Qt-core, and I've never actually used it or Boost C++ for that matter, but I'm just wondering if should maybe be considered, as it may have merits. That said, as you're likely going to be the main person in this code effort, simply having more experience with QT-core than Boost C++ can be a significant and quite valid factor. 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 - I make a branch and work there - and if needed / when we want we merge to trunk Not too much of a strong opinion, except that if you do work on trunk there should be either a tag or branch made for the current state of trunk. Best of luck, Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Le lundi 17 novembre 2008, Nicolas Weeger a écrit : 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. 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 - I make a branch and work there - and if needed / when we want we merge to trunk Opinions? Note that this isn't for tomorrow, some stuff to finish before, maybe in a few weeks :) Nicolas From past experience, I'd tend to lean towards writing a server code from scratch, possibly recycling various elements by cut'n'paste, instead of evolving a codebase that is already of questionable cleanliness. This would also need to lay down a code architecture, split this into tasks, and establish a development schedule. It also obviously require a coding team - the scale of the task would require it to achieve decent results in an acceptable development time. My main concern is that by using the current code base without a solid design map, the result would mostly be a Crossfire with Qt extensions - most griefs I have towards the current code are architectural, and I'm not sure an incremental approach would allow to really solve them. Finally, from your message content, it is hard not to see the intend as being more using Qt than providing something new. Although I strongly believe myself that the use of C++/Qt can lead to a more flexible, less complex code, I wouldn't go on Qt just for the sake of it: why you want to do that and with which planned advantages in terms of features/stability is what I'd want to be defined before judging on my position about this. -- Lauwenmark. Drive defensively: buy a tank. signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
quoth Nicolas Weeger (Mon, 17 Nov 2008 20:07:37 +0100): 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 - I make a branch and work there - and if needed / when we want we merge to trunk I'd like to propose that the best alternative is a third one: You work on trunk, but tag (or even branch) the last revision before the C++ transition. -- I'm using a laptop and forgot to copy my signature file. For the moment, whatever info you want is probably at http://lalomartins.info/ or thereabouts... ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
