Can't wait to try it.
Maybe this will eliminate the whole random member deletions that happens on the flatfile version.

There's a fix for that that's being tested, and probably works somewhere ...

Quoted from pakodi

I don't understand when people talk about complexity in SQL forums. If the installer installs the SQL tables for you in the database, It is straight forward like any other script. The only problem is whether your host supports SQL or NOT.

From the current scenario, looks like Justin is not getting enough support from other people on Eblah Project to push forward the SQL version

But the advantages for the new SQL version would be Speed, Reliability and wider acceptance. This should not be ignored .

I hope Justin will not give up although I understand that he needs more support for the version to be complete.

Either way will wait few more days/weeks on how this issue progresses.

Ok, let me see if I can break this down for you.

1.  My host supports SQL, and I tried to install Justin's version from this weekend on my beta site.  No go.  Justin says that it is because he is using version of DBI (or something like that) than my host is running...so it didn't run.  

2.  Maybe if Justin was the most knowledgeable SQL programmer in the world, he would be able to ensure that E-Blah would run on every server in the world, but he is not.  While he is leaps and bounds past my knowledge level of it, he is one person writing the code for E-Blah.

3.  Then there is sleep and relaxation time.  I assume that Justin is not a machine (though sometimes I wonder).  This means that the man needs to sleep eat and have fun some time during the day

4.  The goal is that E-Blah succeeds  as the best forum software available to the public for free.  If this means that supporting two versions would limit that ability, then I say that he sticks with one.

That being said, I do support the SQL version.  It does open up (in my eyes), "paid" versions of E-Blah.  Personally Justin, I don't know why you would release a free version of something that is better than what people are already paying money for...but that is just me  

One last thing.  You say:

Quoted from pakodi

But the advantages for the new SQL version would be Speed, Reliability and wider acceptance. This should not be ignored .

I know that Justin has mentioned speed before, so I am not doubting that an SQL version would be .005 sec faster, but when it comes to reliability and acceptance, an SQL version would not give me any more of that.  I have been running E-Blah boars with no problems for 3 years now, and there are other boards with a lot more posts out there that have been running even longer.

I'm sorry if I seem rude, but don't look a gift horse in the mouth.  It is not that I don't support the SQL version, but if it becomes the primary distribution, then it needs to cover 100% of the people that want to install it, not 2%.


-Craig.

Craig, be sure to try out the beta.  

And since I started the MySQL version until about 23 Feb, I probably spent on average of about 8 hours per day on it (if not more).  It was draining all of my time, and I was getting very frustrated as to how it would turn out.  I do depend on donations to E-Blah, and so there were also those goals as to whether or not I should start/stop the SQL version (and why I chose to not fully support it as of now, and possibly not release a final version).


That said though, I also wouldn't want 3 or 4 weeks of programming to just go to complete waste.  

Also, I hope we can get your issue solved, Craig.  

Quoted from Craig

Ok, let me see if I can break this down for you.

1.  My host supports SQL, and I tried to install Justin's version from this weekend on my beta site.  No go.  Justin says that it is because he is using version of DBI (or something like that) than my host is running...so it didn't run.  

2.  Maybe if Justin was the most knowledgeable SQL programmer in the world, he would be able to ensure that E-Blah would run on every server in the world, but he is not.  While he is leaps and bounds past my knowledge level of it, he is one person writing the code for E-Blah.

3.  Then there is sleep and relaxation time.  I assume that Justin is not a machine (though sometimes I wonder).  This means that the man needs to sleep eat and have fun some time during the day

4.  The goal is that E-Blah succeeds  as the best forum software available to the public for free.  If this means that supporting two versions would limit that ability, then I say that he sticks with one.

That being said, I do support the SQL version.  It does open up (in my eyes), "paid" versions of E-Blah.  Personally Justin, I don't know why you would release a free version of something that is better than what people are already paying money for...but that is just me  

I don't mind if EBlah SQL version is a paid one as long as it stays in the affordable range of 15-25$. That being said, it would mean some one who is proficient in MYSQL should be hired initially to go through the code and make necessary changes, which will help run it on all SQL versions.
I understand that Justin is putting lot of effort, thats why I asked him to take 2-3 months for sql version if required, so that he can get more people with SQL Knowledge to help him out and the burden is shared equally.

Quoted from Craig

One last thing.  You say:

I know that Justin has mentioned speed before, so I am not doubting that an SQL version would be .005 sec faster, but when it comes to reliability and acceptance, an SQL version would not give me any more of that.  I have been running E-Blah boars with no problems for 3 years now, and there are other boards with a lot more posts out there that have been running even longer.

The reason I said reliability is that often some files related to board data gets truncated or members data get lost and this seems to be the common problem with most users on shared hosting. Unless you have a backup data for every day, its an embarrassing situation to keep answering the users on forum every day when they ask me "why my ID was reset".

The problem comes when your shared hosting provider allows you to install perl based scripts in "cgi-bin" only.
Often cgi-bin space/resources is limited and this results in member/board data getting truncated now and then. I didn't new about this earlier and even thought of switching to simple machines forum at one point.

But then, I came to know that my hosting plan supports to install perl/cgi scripts wherever I want outside "cgi-bin" and I happened to resolve the data loss issue to large extent by installing Eblah outside "cgi-bin". But when the traffic is high, some times I have 150 users online some times, I see that couple of members data or statistics data do get truncated or lost.

These issues to large extent can be resolved with SQL backend in my opinion. However finally its Eblah founders/supporters call if they want an SQL version or not

Quoted from Craig

I'm sorry if I seem rude, but don't look a gift horse in the mouth.  It is not that I don't support the SQL version, but if it becomes the primary distribution, then it needs to cover 100% of the people that want to install it, not 2%.

This is debatable. When you say 2% of 100% that means 2000 current Eblah users using flatfile version. But my opinion is that this 2000 can become 10,000 if an SQL version comes out, since 85% of other forums are SQL based. SO for me your statistics won't make any sense.

Anyway since I am on a dedicated server right now, I don't have any issues with Eblah flatfile version as of now.

But as far as growth fo EBlah is concerned Eblah group has to decide

a) whether it wants to remain flat file version ( would mean 10-20% target market) i.e an alternative to boards which are SQL based

or

b) compete with other forums irrespective of versions ( 80% of market)


The issue finally comes down to Justin, who is doing 90% of the work with EBlah, where as if you see other forum softwares they have atleast 10-12 people in their core team designing new modules. So if Justin can find some alternatives good for him(i.e more people to helping him out) and Eblah, if he is going to do everything from flat-file to SQL then that's asking for 200% which I agree is too much.

Quoted from pakodi

But then, I came to know that my hosting plan supports to install perl/cgi scripts wherever I want outside "cgi-bin" and I happened to resolve the data loss issue to large extent by installing Eblah outside "cgi-bin". But when the traffic is high, some times I have 150 users online some times, I see that couple of members data or statistics data do get truncated or lost.

These issues to large extent can be resolved with SQL backend in my opinion.

This could also be combined with a bug, that should have been fixed in either nightlies OR with a patch found on the support board.

Quoted from pakodi

However finally its Eblah founders/supporters call if they want an SQL version or not

I'm the only one who works on it ...

Quoted from pakodi

This is debatable. When you say 2% of 100% that means 2000 current Eblah users using flatfile version. But my opinion is that this 2000 can become 10,000 if an SQL version comes out, since 85% of other forums are SQL based. SO for me your statistics won't make any sense.

Yeah, but 90% of them are also PHP based too.  PHP is good for certain things.  Perl is better at others.  The in betweens are simply a matter of preference.  I like Perl better because I know it, and because it's not strictly a web language as PHP primarily is (PHP is NOT 100% a web-only language, mind you).

Quoted from pakodi

The issue finally comes down to Justin, who is doing 90% of the work with EBlah, where as if you see other forum softwares they have atleast 10-12 people in their core team designing new modules. So if Justin can find some alternatives good for him(i.e more people to helping him out) and Eblah, if he is going to do everything from flat-file to SQL then that's asking for 200% which I agree is too much.

I've not come across anyone who's that dedicated and I also haven't wanted to share coding because there's certain styles that I like AND I do not comment my code, as I probably should.  You can ask any of the support team and find that I do not like using others code.  It's not that I dislike them, I just don't like changing things around and not knowing where things are at and such.  I like coding it myself as it's more centralized, quicker to do, and overall a better product is produced usually (with one man teams).  The down side is those who aren't dedicated and take years for a few bug fixes.  Over the past five years I've had the time to keep E-Blah maintained, so there's been releases pretty regularly.

Appreciate your efforts Justin.

You make some good points pakodi.

-Craig.

Quoted from Craig

You make some good points pakodi.

-Craig.

Try out the latest version from the downloads page -- it should now work for you.  

People say that SQL is faster than flat file.  The truth is it's simply not (in itself).

SQL is more flexible and has the index.  Flatfile does not.  Whether you program in Perl or PHP, if you construct the index correctly, and are a competent flatfile programmer... flatfile  is no better or worse than SQL.

I'd STILL say keep developing the flatfile and drop the SQL version.  Flatfile is why people come to E-Blah.  If it's not supported and actively developed anymore, I think there'll be an exodus of users

Read this:

http://www.eblah.com/forum/m-1172772869/

Congrats on your new daughter too!  Way to go proud father!

Quoted from Ryan

People say that SQL is faster than flat file.  The truth is it's simply not (in itself).

SQL is more flexible and has the index.  Flatfile does not.  Whether you program in Perl or PHP, if you construct the index correctly, and are a competent flatfile programmer... flatfile  is no better or worse than SQL.

I'd STILL say keep developing the flatfile and drop the SQL version.  Flatfile is why people come to E-Blah.  If it's not supported and actively developed anymore, I think there'll be an exodus of users

Quoted Text

There has been worry that this version will be the successor to the flat-text version.  This is not the true.  The flat-text version will still be maintained (and in fact, has been so far).  The MySQL version is completely separate from the flat-text version.

http://www.eblah.com/forum/m-1172773755/