Go Back   vb.org Archive > vBulletin 3 Discussion > vB3 General Discussions
FAQ Community Calendar Today's Posts Search

Reply
 
Thread Tools Display Modes
  #1  
Old 03-14-2004, 08:38 AM
buro9 buro9 is offline
 
Join Date: Feb 2002
Location: London, UK
Posts: 585
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default Fixing vBulletin and bringing the hacker community back together.

I want to gauge an opinion here, and preferably with some input from users of everythingVb, vBulletin.nl, and all of the other hack sites. However I shall only post here solely to allow the discussion to exist in one place.

There are essentially two things that I would like to ponder:
  1. Turning vBulleting into an Enterprise product and adding a developer API.
  2. Giving the hack community a single, searchable breakdown of all hacks, template changes and modifications.

Turning vBulleting into an Enterprise product and adding a developer API.

As I see it vBulletin is quite simply the best forum software there is, I've been using it for ages and hacking the hell out of mine for almost as long.

Now, I work as a Senior Developer and in the past few years have worked for British Telecom and a few other FTSE100 companies... all of which had a need for forum software, none of which purchased vBulletin no matter how much I put the case forward.

To my mind, vBulletin has never cracked the Enterprise market... and in turn we lesser users haven't benefited from the improvements that an Enterprise version would bring us (improved stability, normalised database, external user database, database abstraction layer, choice of scripting language, increase scalability).

When I worked at Premium TV (we did football sites for the UK football clubs), we could expect 40,000 people online on a Saturday afternoon at one time. Nowhere could we find evidence that vBulletin could cope with this, and table locking in MySql suggested to us that it simply could not. Further... with 80 clubs to run sites for we would've purchased 80 licenses, however we would only have desired 1 codebase to maintain.



So here is my proposal: That the community of hackers take it upon themselves to offer a major hack to produce an Enterprise version of vBulletin.

My experience would say that these were some of the requirements of this:
  • Database Normalisation: Do away with MySql specific features or MySql based tricks (such as overloaded ID columns where a join would have been better).
  • Database Abstraction Layer: To have a plugin file hold the queries and take advantage of specific database features (the Oracle plugin would use Stored Procs and bind variables for example, and maybe even the Intermedia cartridge for searching), this is dependant on normalisation.
  • External User Database: Store local user preferences and signature, etc, but to have done core authentication against an admin defined custom database schema or LDAP.
  • Scripting Language Choice: Allow both Java and C# to be used as the front-end instead of PHP.
  • A developer API for performing common tasks, such as sending PM's, E-mails, etc. This would need to be for each scripting language and would assist the companies in developing rapidly their own extensions without having to delve deeply into the vBulletin codebase.
  • vBulletin Engine: Add a site flag and a site_hosts table to map domains to configurations. In effect to allow one codebase to power many sites (Each URL would have to be a seperate paid license of course).

Now that is an enormous amount of work... and something would be daunting for anyone. It's tantamount to a re-write of the ways in which vBulletin does things, almost a core re-write to accomodate some things (like database normalisation and abstraction).

The question would be asked whether this is an extension (major) to vBulletin or a seperate product (vBulletin Enterprise?), and in the case of the latter the relationship that would have to Jelsoft (would they sell it and take upon the additional staff, etc?) or whether it would be legit to create a totally seperate product, open source or paid... etc, etc. But for now the question is whether this could be achieved in the first place... the best way to go about it can be answered later.

But the benefits are huge, not least the choice of many databases very easily and the advantages each offers (row locking, permissioning, stored procs, tree-walking, transactions, searching, etc). But also for those with Windows boxes to be able to pick ASP .Net and C# and those with UNIX boxes to select a Java Tomcat version.

Organisations of this size already have Oracle DBA's, or Sql Server DBA's, they aren't especially willing to take on MySql.
They already have server farms and load balancing and redundancy for their Windows or UNIX web servers... they aren't willing to install PHP and manage that.
They already have their user database and a single-signon policy, they aren't willing to make their users register again.

So the above proposals are to help solve all of those and in turn give the vBulletin community an Enterprise branch of code that will be able to scale to tens of thousands online simultaneously (of course dependant on your hardware, but you can scale through multiple web servers with load balancing in front, caching for non-dynamic things and using Oracle clustering or a similar technology at the back).


Giving the hack community a single, searchable directory of all hacks, template changes and modifications.

Years of watching the hacker community splinter in ego driven tugs of war and petulance. Well I would love to say don't go there, but we have and the damage has already been done.

So what I propose here is not a forum! It's a Wiki... a simple web-site changeable by all, to be non-promoting of each community site and to act as a factual and searchable repository of all of the vBulletin hacks and extensions that exist, those that are paid for and those that are given back to the community for free.

It would NOT be a place to publish hacks, it would simply be a place to find out if a hack exists and where it can be found.

So this proposal is simply to use a Wiki to create a searchable directory of vBulletin hacks, modifications, additions, extensions, template changes, etc.

These would not be categorised by the type of change (template, code, new file), but by what they achieve... so the blink on new PM hack AND template change would both exist in the same place: Forum Home Enhancements.

No non-factual information would be stored... There would be none of the "This is the bestest and greatest hack for... " type thing... it would be just a factual description only.

As such it would act as a gateway to all of the communities, and the glue between them.

Now a fair few of the heavy users would argue that there is no need for this, that we know where to find things... yes, we do... but newbies and less frequent visitors do not, and remain lost in all of these sites and communities not understanding the personal politics that exist between some and the strange policies that each site has about how hacks, etc are published.

So that is the vBulletin Directory.


Summary
So there were the two proposals: One is an enormous piece of work to open vBulletin up to corporate customers and the other a way to help vBulletin administrators locate all changes across all of the developer communities and glue it all back together.

These are only proposals.

I think it's good to discuss such stuff, especially since the latter one shouldn't be driven by any particular owner or ego.

So please feedback what you think of them.

Cheers

David K
Reply With Quote
  #2  
Old 03-14-2004, 09:01 AM
Floris Floris is offline
 
Join Date: Jan 2002
Posts: 1,898
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Quote:
Originally Posted by buro9
I want to gauge an opinion here, and preferably with some input from users of everythingVb, vBulletin.nl, and all of the other hack sites. However I shall only post here solely to allow the discussion to exist in one place.

There are essentially two things that I would like to ponder:
  1. Turning vBulleting into an Enterprise product and adding a developer API.
  2. Giving the hack community a single, searchable breakdown of all hacks, template changes and modifications.

Turning vBulleting into an Enterprise product and adding a developer API.

As I see it vBulletin is quite simply the best forum software there is, I've been using it for ages and hacking the hell out of mine for almost as long.

Now, I work as a Senior Developer and in the past few years have worked for British Telecom and a few other FTSE100 companies... all of which had a need for forum software, none of which purchased vBulletin no matter how much I put the case forward.

To my mind, vBulletin has never cracked the Enterprise market... and in turn we lesser users haven't benefited from the improvements that an Enterprise version would bring us (improved stability, normalised database, external user database, database abstraction layer, choice of scripting language, increase scalability).

When I worked at Premium TV (we did football sites for the UK football clubs), we could expect 40,000 people online on a Saturday afternoon at one time. Nowhere could we find evidence that vBulletin could cope with this, and table locking in MySql suggested to us that it simply could not. Further... with 80 clubs to run sites for we would've purchased 80 licenses, however we would only have desired 1 codebase to maintain.



So here is my proposal: That the community of hackers take it upon themselves to offer a major hack to produce an Enterprise version of vBulletin.

My experience would say that these were some of the requirements of this:
  • Database Normalisation: Do away with MySql specific features or MySql based tricks (such as overloaded ID columns where a join would have been better).
  • Database Abstraction Layer: To have a plugin file hold the queries and take advantage of specific database features (the Oracle plugin would use Stored Procs and bind variables for example, and maybe even the Intermedia cartridge for searching), this is dependant on normalisation.
  • External User Database: Store local user preferences and signature, etc, but to have done core authentication against an admin defined custom database schema or LDAP.
  • Scripting Language Choice: Allow both Java and C# to be used as the front-end instead of PHP.
  • A developer API for performing common tasks, such as sending PM's, E-mails, etc. This would need to be for each scripting language and would assist the companies in developing rapidly their own extensions without having to delve deeply into the vBulletin codebase.
  • vBulletin Engine: Add a site flag and a site_hosts table to map domains to configurations. In effect to allow one codebase to power many sites (Each URL would have to be a seperate paid license of course).

Now that is an enormous amount of work... and something would be daunting for anyone. It's tantamount to a re-write of the ways in which vBulletin does things, almost a core re-write to accomodate some things (like database normalisation and abstraction).

The question would be asked whether this is an extension (major) to vBulletin or a seperate product (vBulletin Enterprise?), and in the case of the latter the relationship that would have to Jelsoft (would they sell it and take upon the additional staff, etc?) or whether it would be legit to create a totally seperate product, open source or paid... etc, etc. But for now the question is whether this could be achieved in the first place... the best way to go about it can be answered later.

But the benefits are huge, not least the choice of many databases very easily and the advantages each offers (row locking, permissioning, stored procs, tree-walking, transactions, searching, etc). But also for those with Windows boxes to be able to pick ASP .Net and C# and those with UNIX boxes to select a Java Tomcat version.

Organisations of this size already have Oracle DBA's, or Sql Server DBA's, they aren't especially willing to take on MySql.
They already have server farms and load balancing and redundancy for their Windows or UNIX web servers... they aren't willing to install PHP and manage that.
They already have their user database and a single-signon policy, they aren't willing to make their users register again.

So the above proposals are to help solve all of those and in turn give the vBulletin community an Enterprise branch of code that will be able to scale to tens of thousands online simultaneously (of course dependant on your hardware, but you can scale through multiple web servers with load balancing in front, caching for non-dynamic things and using Oracle clustering or a similar technology at the back).


Giving the hack community a single, searchable directory of all hacks, template changes and modifications.

Years of watching the hacker community splinter in ego driven tugs of war and petulance. Well I would love to say don't go there, but we have and the damage has already been done.

So what I propose here is not a forum! It's a Wiki... a simple web-site changeable by all, to be non-promoting of each community site and to act as a factual and searchable repository of all of the vBulletin hacks and extensions that exist, those that are paid for and those that are given back to the community for free.

It would NOT be a place to publish hacks, it would simply be a place to find out if a hack exists and where it can be found.

So this proposal is simply to use a Wiki to create a searchable directory of vBulletin hacks, modifications, additions, extensions, template changes, etc.

These would not be categorised by the type of change (template, code, new file), but by what they achieve... so the blink on new PM hack AND template change would both exist in the same place: Forum Home Enhancements.

No non-factual information would be stored... There would be none of the "This is the bestest and greatest hack for... " type thing... it would be just a factual description only.

As such it would act as a gateway to all of the communities, and the glue between them.

Now a fair few of the heavy users would argue that there is no need for this, that we know where to find things... yes, we do... but newbies and less frequent visitors do not, and remain lost in all of these sites and communities not understanding the personal politics that exist between some and the strange policies that each site has about how hacks, etc are published.

So that is the vBulletin Directory.


Summary
So there were the two proposals: One is an enormous piece of work to open vBulletin up to corporate customers and the other a way to help vBulletin administrators locate all changes across all of the developer communities and glue it all back together.

These are only proposals.

I think it's good to discuss such stuff, especially since the latter one shouldn't be driven by any particular owner or ego.

So please feedback what you think of them.

Cheers

David K
vBulletin.nl is not a hack site, it is a vBulletin fan site. There is a source code section yes, but that doesn't mean it is a hack site. Don't pull my site into your quests. Thank you.
Reply With Quote
  #3  
Old 03-14-2004, 09:53 AM
MindTrix's Avatar
MindTrix MindTrix is offline
 
Join Date: Apr 2002
Location: United Kingdom
Posts: 1,833
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

On your first suggestion wouldnt that be nearly re-making vB which is up to the vB team not us? And we wouldnt be able to release the files would we, mearly write down all the changes and from what you said, would be alot.

On the second point, i dont see whats difficult about going to vb.org for hacks and vb.org for templates and using their search engines :P:P

Just my 2 cents
Reply With Quote
  #4  
Old 03-14-2004, 12:04 PM
13th_Disciple 13th_Disciple is offline
 
Join Date: Jan 2003
Posts: 262
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Quote:
Originally Posted by floris
Don't pull my site into your quests. Thank you.
I don't see where your site was specifically mentioned in his post.. It is an opinion about how to bring together all for a singular common good. I see nothing bad about that and don't see it as a "quest" of any kind..

Nice post, buro9.. i for one think it is a good idea. But I doubt there is much, if any formal support for either of your suggestions.. Also, the open source idea, it generally doesn't fly around here as everyone "has to get paid" for their services or it isn't worth their time..

i also don't believe some of the things you are looking for out of MySQL are available yet.. Isn't it ver. 5 that will finally support stored procedures? t may do it now, but I thought it was 5 that will support it.. Also, the external user information would make it easy to develop a ton of other things.. as well as be able to pass that information across different authentication protocols..

i really like the vBulletin software, but I really can't stand some of the attitudes from some of the people involved in the heirarchy of it all.. It makes it seem as if you must be loyal to them or worthy of their time before anyone anywhere invlves themselves in anything someone may ask.. there have been a few helpful folks, but most of them are few and far between anymore.. and with sites spreading out, people not caring and no one in the upper eschelon paying attention, it will only get worse..

that is also my 2 cents.. but I am not the only one here who thinks things are falling apart. and aparently, offering ideas to pull things together such as buro9 suggested, already get the drop kick right from the get go.. gg folks..
Reply With Quote
  #5  
Old 03-14-2004, 01:12 PM
sabret00the's Avatar
sabret00the sabret00the is offline
 
Join Date: Jan 2003
Location: London
Posts: 5,268
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

not a bad idea but have you actually spoken to anyone over at .com about this?
Reply With Quote
  #6  
Old 03-14-2004, 02:00 PM
Dean C's Avatar
Dean C Dean C is offline
 
Join Date: Jan 2002
Location: England
Posts: 9,071
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Let me just pick up on two points:

Quote:
# External User Database: Store local user preferences and signature, etc, but to have done core authentication against an admin defined custom database schema or LDAP.
This as many people here have been saying is a good idea. I'd like to see an option to store all user related data in an external database with the option to link to it. That'd make it a lot easier to have cross-site user databases. I have a feeling that this'll be added in vB3.1 as you wouldn't believe the time we've been asked this here.

Quote:
# Scripting Language Choice: Allow both Java and C# to be used as the front-end instead of PHP.
Well vBulletin is a soley PHP program. Alongside with keeping up with features, bugs and other support-related issues - I can never see this happening
Reply With Quote
  #7  
Old 03-14-2004, 07:05 PM
Brad Brad is offline
 
Join Date: Nov 2001
Posts: 4,765
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

IMO the one thing jelsoft needs to do is build a database api for vBulletin. This would allow you to run vbulletin on a wide rang of database servers. I don't see the point in trying to have multiple sets of the source code, I think that would hurt development more then it would help.
Reply With Quote
  #8  
Old 03-14-2004, 07:51 PM
13th_Disciple 13th_Disciple is offline
 
Join Date: Jan 2003
Posts: 262
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

then make an open source distribution of vBulletin.. comes with zero support, zero aid from jelsoft proper.. and contributions are dependant on community input alone.. therefore it can be ported to whatever a person sees fit..

so for a full service, fully supported, ready to run forum setup, you buy your license.. else you opt for an open source code for vBulletin that has none of the above.. it has the basic functionality to run, but past that, it's all up to the end user and community to figure it out..

and to point to a very good case.. FreeBSD.. it is fully free, ready to run, but zero support except from the community.. however, you can get the handbook, all CD's and such for about 60 dollars..

it can also open up a lot of folks to input ideas and info into vBulletin that otherwise have no way to buy a leased or owned license..
Reply With Quote
  #9  
Old 03-14-2004, 08:51 PM
ap0c's Avatar
ap0c ap0c is offline
 
Join Date: Mar 2003
Posts: 210
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Quote:
Originally Posted by 13th_Disciple
then make an open source distribution of vBulletin.. comes with zero support, zero aid from jelsoft proper.. and contributions are dependant on community input alone.. therefore it can be ported to whatever a person sees fit..

..
jelsoft would lose alot of money on that deal. Most people like free things better than paying for them,bugs or not
Reply With Quote
  #10  
Old 03-14-2004, 11:13 PM
13th_Disciple 13th_Disciple is offline
 
Join Date: Jan 2003
Posts: 262
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

or potentially open their business to an entire level that has not yet been tapped..

besides.. if this draws little interest.. it would die rather quickly.. i seriously doubt it would put as much of a dent in their pocket book as some folks think..
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 03:10 AM.


Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2024, vBulletin Solutions Inc.
X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.04692 seconds
  • Memory Usage 2,300KB
  • Queries Executed 13 (?)
More Information
Template Usage:
  • (1)SHOWTHREAD
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (1)ad_showthread_beforeqr
  • (1)ad_showthread_firstpost
  • (1)ad_showthread_firstpost_sig
  • (1)ad_showthread_firstpost_start
  • (5)bbcode_quote
  • (1)footer
  • (1)forumjump
  • (1)forumrules
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (1)navbar
  • (3)navbar_link
  • (120)option
  • (1)pagenav
  • (1)pagenav_curpage
  • (2)pagenav_pagelink
  • (10)post_thanks_box
  • (10)post_thanks_button
  • (1)post_thanks_javascript
  • (1)post_thanks_navbar_search
  • (10)post_thanks_postbit_info
  • (10)postbit
  • (10)postbit_onlinestatus
  • (10)postbit_wrapper
  • (1)spacer_close
  • (1)spacer_open
  • (1)tagbit_wrapper 

Phrase Groups Available:
  • global
  • inlinemod
  • postbit
  • posting
  • reputationlevel
  • showthread
Included Files:
  • ./showthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/functions_bigthree.php
  • ./includes/class_postbit.php
  • ./includes/class_bbcode.php
  • ./includes/functions_reputation.php
  • ./includes/functions_post_thanks.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_postinfo_query
  • fetch_postinfo
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • showthread_start
  • showthread_getinfo
  • forumjump
  • showthread_post_start
  • showthread_query_postids
  • showthread_query
  • bbcode_fetch_tags
  • bbcode_create
  • showthread_postbit_create
  • postbit_factory
  • postbit_display_start
  • post_thanks_function_post_thanks_off_start
  • post_thanks_function_post_thanks_off_end
  • post_thanks_function_fetch_thanks_start
  • post_thanks_function_fetch_thanks_end
  • post_thanks_function_thanked_already_start
  • post_thanks_function_thanked_already_end
  • fetch_musername
  • postbit_imicons
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • postbit_display_complete
  • post_thanks_function_can_thank_this_post_start
  • pagenav_page
  • pagenav_complete
  • tag_fetchbit_complete
  • forumrules
  • navbits
  • navbits_complete
  • showthread_complete