Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yahoo!, DotBot

Members: 0
Guests: 6
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
612
Jacki72H
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » AFKMud Support & Development » MySQL DB Support: Wanted or n...
Forum Rules | Mark all | Recent Posts
MySQL DB Support: Wanted or not? (17 Votes)
Yes - As a stock feature, required for install.  35.29% - 6 votes

Yes - As a stock feature, but not required.  52.94% - 9 votes

Yes - But as a separate snippet.  11.76% - 2 votes

No - I can't ever see a need for DB support at all.  0% - 0 votes

MySQL DB Support: Wanted or not?
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2 next >>
Post is unread #1 Nov 5, 2006, 12:13 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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?
       
Post is unread #2 Nov 5, 2006, 12:53 pm
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

Optional is the best route.
       
Post is unread #3 Nov 5, 2006, 2:07 pm
Go to the top of the page
Go to the bottom of the page

KazRo

GroupMembers
Posts41
JoinedSep 29, 2005

Kigen said:

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.
       
Post is unread #4 Nov 5, 2006, 2:22 pm
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

Quite often people running muds will not have MySQL, or atleast to the people I think you are targetting with this.
       
Post is unread #5 Nov 5, 2006, 2:40 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

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. :wink:
       
Post is unread #6 Nov 5, 2006, 2:48 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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.
       
Post is unread #7 Nov 5, 2006, 6:04 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

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.. :thinking:
       
Post is unread #8 Nov 5, 2006, 6:05 pm
Go to the top of the page
Go to the bottom of the page

KazRo

GroupMembers
Posts41
JoinedSep 29, 2005

I also would have to change my answer to required on install.
       
Post is unread #9 Dec 2, 2006, 1:12 am
Go to the top of the page
Go to the bottom of the page

Oshuma

GroupMembers
Posts6
JoinedDec 2, 2006

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. :wink:
       
Post is unread #10 Dec 2, 2006, 1:51 am
Go to the top of the page
Go to the bottom of the page

KazRo

GroupMembers
Posts41
JoinedSep 29, 2005

Oshuma said:

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.


The problem with optional is what Samson had said before.

Samson said:

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.


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?
       
Post is unread #11 Dec 8, 2006, 4:02 pm
Go to the top of the page
Go to the bottom of the page

Zarius
Apprentice
GroupMembers
Posts69
JoinedApr 23, 2002

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.
       
Post is unread #12 Dec 8, 2006, 4:18 pm
Go to the top of the page
Go to the bottom of the page

kiasyn
Magician
GroupMembers
Posts121
JoinedJun 30, 2006

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.
       
Post is unread #13 Dec 8, 2006, 7:20 pm
Go to the top of the page
Go to the bottom of the page

Zarius
Apprentice
GroupMembers
Posts69
JoinedApr 23, 2002

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.
       
Post is unread #14 Dec 8, 2006, 10:21 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Again, upload a copy to mudbytes too. :smile:
       
Post is unread #15 Dec 10, 2006, 2:36 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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.
       
Post is unread #16 Dec 10, 2006, 7:31 pm
Go to the top of the page
Go to the bottom of the page

KazRo

GroupMembers
Posts41
JoinedSep 29, 2005

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 :tongue:
       
Post is unread #17 Dec 10, 2006, 7:35 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

What do you mean by a full support patch?
       
Post is unread #18 Dec 10, 2006, 8:36 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Oh, not yet another damn patch file rather than a straight forward snippet.. please. *sigh* :sad:
       
Post is unread #19 Dec 10, 2006, 9:08 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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.
       
Post is unread #20 Dec 11, 2006, 2:53 am   Last edited Dec 11, 2006, 2:58 am by Conner
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

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.
       
Pages:<< prev 1, 2 next >>