Generic Architecture

[Doodman]

In rebuttal:

1) The actual netcode is encapsulated pretty well at this point. Most of zone/world did not have to change with the new netcode (except that I esstenially renamed APPLAYER to EQApplicationPacket). I basically rewrote the lower level (and tried to preserve the API structure as made sense) and the plugged it in and tweaked it.

2) I completely agree. But this is a -major- undertaking. The new eqcollector (replaced packet collector) is very modular and supports the use of plugins for processing the packets. The major issue here is the way windows uses DLL's (at least in vs.*). In unix a shared object is brought in to the memory space of the running executable and can directly call the functions in there. Not so in windows. Doing this would involve putting -everything- that might need to be called into a series of DLL's, which is of course doable.

3) I agree, in principle. But, you'll get a very small return on the time investment. Mysql is the most popular opensource database followed, probably, by PostgreSQL (which I prefer). I don't forsee anyone using Oracle or Sybase or SqlServer for a eqemu backend, it's either outright piracy or it's cost prohibitive.

4) First of all, to me this is not "network code". This is application transport level (i.e. spawn struct, player profile struct, etc). If you are talking about a preprocessed ML for generating C/C++ structs/functions, yeah that'd be great. I started on this as well, at least in theory. Having each object know how to build the packets that it's interested in. That way it's completely encapsulated and can be changed without affecting external code. Having a ML to generate those methods would be great. I have concerns about having it purely dynamic during runtime. It would be very hard to do effeciently on the server (clients have it easy). Remember, multiple the work the client has to do in these cases by 10, 20, 80, 100, however many people are on the server. More work = more lag = more instability.

5) I kind of agree with this. More threads isn't always a good thing. More to manage, more to join back in, more to coordinate. And as far a taking advantage of a SMP machine, if you have multiple people in multiple zones, you already are doing so. Adding more threads may not help, plus I'd wager a lot of things done per client can't reallt be done in parallel outside of slower database type things (like saving).

I'll add #6. There are a lot bigger issues with the eqemu code (bugs, stability issues, live compat, etc) that I feel a lot of this time and energy could be focused on.

I'm not trying to be a nay-sayer, but more of a realist. These are great ideas and things that I agree with on principle. Some of them may not be worth the effort when you look at the bang you'll get for your time/effort -buck.

[Trumpcard]

From an architectural design perspective, heres my comment..

I'd just stick with mysql.. its completely portable and lightweight, and it'll keep your support channels down. Go out to too many database systems and you'll end up with endless installation, configuration and support questions for a myrid of database systems. Just do yourself a favor and lock the database requirements.

I'd also consider trying to gear towards mysql 5 and writing as much as possible as stored procedures. The queries for the most part will be really simple, but doing them as stored procedures will make the queries alot easier to support (they'll be in a master mysql stored proc definition file versus scattered all throughout the code in inlined queries ) , and from a performance engineering perscpestive, it'll be ALOT easier to track down poorly performing database calls by using the server side performance timings and call frequencies that the database itself will generate. Needed optimizations will be alot easier to perform, as you'll have better metric data to decide what needs to be optimized.

Also, doing the calls as stored procedures, it'll make it easy for you to develop add on tools in other languages such as PHP (web interfaces/info sites) that exploit the exact same stored procedures to retrieve data without having to reinvent the data calls inside a different language. I know from experience that 20 different people developed 20 independent web tools and what not so there was a ton of code duplication in terms of the queries. Just make a set of stored procedures that handle all those requests and when new folks need new types of queries, just merge them into the SP base.

[BlueHi]

I agree 100% with Trumpcard. Although I use coldfusion instead of php I could do the exact same thing. I would love to see stored procedures. Maybe I am talking about something a little differant but here is how I would use them. I work with SQLserver and don't know to much about mysql. With my experience of working with stored procedures and using web based code like php and coldfusion is that you don't need to know how the program works you only need to know what value's the stored procedures returns which is great. This makes development a lot faster and also it can be used over and over again in other programs. Like I say I don't know much about php but in coldfusion I would simply just include a program that uses the stored procedure so there would be no duplication for that query. I am not so sure how much that would benifit the development of EQEmu but I do know that it would help those of us who link a website to there database for eqemu.