So. I may as well ask.

As it currently stands in 2.0, the SQL support is included and is also required for install, and the help files are already converted to use it exclusively. We don't intend to change this for Alsherok, but since we've been burned once already on a high demand feature that later gets ripped out.....

So before cutting for release, this question obviously needs to be answered. How do you guys want to handle the DB support?

Optional is the best route.

I agree, It may be asking to much of people to require them to install something they may not use.

Quite often people running muds will not have MySQL, or atleast to the people I think you are targetting with this.

I think folks who intend to run a mud that don't have MySQL available to them really should be looking at running a codebase that doesn't use MySQL, trying to downgrade the codebase because some folks want to try anyway seems counter productive and adding MySQL support seems like such a good idea to me. *shrug*

I do agree that having it optional is prolly better for those that love to rip stuff out of codebases routinely, but personally I'd prefer to see it as a snippet so it can be more easily ported to SmaugFUSS... but I'm just selfish that way.

There is a caveat to consider here - I probably should have mentioned it sooner, but in making it a separate snippet that would only include the core support necessary to produce a database for use by the mud. That would not include doing anything actually useful with it. There would be no way to guarantee the state of whatever data was going to be imported into it and will require the writing of extra conversion routines to generate the new database info.

The same is true to a lesser extent if it's included stock, but not activated by default. Though in this state there will be support built in for the help files to get things started, and there will be a conversion routine to turn the existing help system into the database.

That being said, any mudhost these days worth their shit will have the ability to provide a database, and the better ones who aren't profit mongering scumbags will give it to you as part of your package.

In that case, I should prolly change my response to making it required on install so that full functionality is already there. But it's going to make it harder by far to steal from AFK for my own code..

I also would have to change my answer to required on install.

I agree that optional is the best way. Have the functionality available for those who use it, but requiring a MySQL server is a bit steep. MUDs usually don't take up many system resources, which is why they can be run on older hardware (which is what I'm personally doing). Just my opinion.

With that said, I'm excited about DB support and will probably end up utilizing it.

The problem with optional is what Samson had said before.



While Optional is the best way to go for most things, but when it comes to partial functionality or full functionality I think it would be best to go with full. On a side note how much resources does a MySQL database use, because I didnt think that they used enough to really bring it up other then maybe for the CYGWIN users?

Snippet form wouldn't be too hard, only problem is that you'd have to include functions that convert things to mysql. Like when I did the AFKMud Mysql stuff I wrote a function that looped through the help files and inserted them into the db, afterward I removed all the text help file loading stuff. Maybe I'll take that on as a project since I'm spinning my wheels waiting on 2.0.

I actually have a standalone convert program I used for converting helpfiles and socials for drazon. Don't think it'd work in this case though.

I posted my AFKMud patch for MySQL on mudfiles.com if anyone is interested. Its pretty simple to get going and I included a sql dump of the db with the stock help files in it already.

Again, upload a copy to mudbytes too.

Bleh. This is becoming more of a hassle than I bargained for. Trying to write up support to maintain two different help systems isn't worth the time, and at this stage I'm not sure it's worth the hassle.

I'm also seriously questioning whether imposing SQL use as mandatory is really the best approach. So I may go against the poll results and return the main distro back to the standard help system with flatfile data and the whole bit and release the SQL code as a snippet for 2.0.

If you wanted to do something like that could you do a full support patch for it? I don't mind installing snippets if I had to but if it was possible to just patch the MySQL system with what support you planned in that would nice

What do you mean by a full support patch?

Oh, not yet another damn patch file rather than a straight forward snippet.. please. *sigh*

Patch files *ARE* straightforward. They don't normally even need instructions, but they do assume one knows what to do with it. Not that patch < patchfile is difficult. You could even do it by hand if you know how to follow the +/- lines.

Writing up a snippet document is actually quite time consuming and bothersome. Especially when there's a very real chance nobody is going to use the code you're releasing. Not to mention that it's not any better to say "Insert this here" when the base someone is trying to install it to doesn't have the place it wants to be inserted.

The downside to patch files is that if you're not dealing with an unaltered codebase, they usually fail which means trying to read them in a text editor or kompare (or smoe other similiar utility) in order to 'follow' them like a snippet, and they don't always have enough information stored in them to clearly indicate exactly where to make each change.

Where when someone writes a snippet, they generally indicate exactly where each change belongs. I'll grant you that writing it as a snippet takes considerably more effort, and that if my codebase doesn't have the function you're telling me to insert this bit of code into at all, I'm no better off than I was with a patch file. But if it's just that my files don't match yours because I've got extra stuff in them, your snippet will be workable where the patch file is not likely to work via the patch command.

I can certainly understand the hesitation to expend the extra effort to snippetize rather than use dif to create a patch file if you really don't think it's going to get use by anyone anyway, but I really have to wonder if that's where you see this one standing after all the discussion that's gone into this. Unless there's something rather wrong with the results of this change-over, I think there are several of us who will almost certainly be using it. Of the 14 votes to date, none have been a no.