UBB.Developers Forums General Discussion Chit Chat UBB API?

Would be interesting to see UBB to use plugins where you run a config script and just add what you want. An example of what I am saying is done by SqirrelMail. Download your plugin into a directory, run the config, select the module and your all set.

its fun to dream. But i think using plgin's for ubb was rejected a while ago.

There are a lot of things that would be nice, like providing security updates for UBB owners that haven't renewed their members area access. Security should never be sonmething you have to pay for...

*shrugs*

I don't think the idea was rejected just that it meant a total rewrite of the UBB which was out of the question at the time.

maybe we can expect such a thing for V7

I think a common API for UBB is a very good idea. i have some ideas how to code but i have no code now...

When did Dave or Ted or I say that the idea was rejected for UBB?

would of been early infopop.com hosting the ubb or late scriptkeeper, but at the time they said it wasn't pratical and would not be server efficient.

things may of changed now, but if you are telling me that the ubb is going to be run on or compatable with plugins, i honestly see it causing more server problems then it does now, because modules/plugins take up more server resources than intergrated code, and the ubb in its present form is doing enough damage to servers.

(not trying to cause ubb efficience arguments, just justifing the reason).

What does modular code have to do with resource use? How are the two related?

I would like you to show me a peice of code that would not increase server load.

I have designed a Control Panel for my site, it uses modules to make it easy to add new sections to, I know it isn't the best solution to run an efficient control panel, it works fine for me, but i wouldn't make a public release based on it while it uses modules.

Yes you could probabily make an efficient one, but can you tell me that you are honestly planning a ubb which supports such a thing with the current flatfile format?

What do flat files have to do with modularity? What does modularity have to do with server load?

Am I planning to do something with the UBB akin to a module / plugin system? Sure, if Dave and Ted OK it and if it fits in with the larger scheme of things. When will this happen? No bloody clue. There are bigger plans to work on right now.

Andrew let me try to clarify what I am desribing as what you are saying has not corelation to my initial post.

By API I mean that you would run ./config.pl (for Unix) Select an option that would be listed say as modules. then a new list would come up with things like, calendar, memberlist, who's online etc. You would be able to select what option you would want. I know this is done through the control panel already with simple radio buttons for on and off but my proposal would allow you do download a hack from UBBDev, place it in the modules directory so that it then would become a selectable option.

I am sure there would be a major revamp in design and code for both UBB and developers but ultimatly this would force standardization for modifications as well as the core of UBB. Thus making things compatable with each other.

Upgrades would also be much easier as the core UBB code could be copied simply into the directory structure without effecting modifications or modifications to modules could also be copied to their respective directories.

The idea that configuration files are seperate from the physical program will allow very quick updates.

This also then allows fixes and additions to smaller modules to be much easier for programmers as they are then dealing with smaller pieces of code that are specific to the module they are working on.

This design would make UBB truely modular as well as making them an industry leader again.

Plus support for IP would be 100% easier as you could just remove hacks not supported by IP without ripping apart your UBB code in a few minutes as well as trouble shooting on your own extremely easy.

The saying we do not support hacked UBBs would be a thing of the past!

Well, we'd have to say "We do not support those modules, so let's turn them off and see if the problems you're having go away". Close enough.

Anyway - yes, what you said is EXACTLY what I've been scheming up.

It's not really as hard as you think it is to implement, nor will it require a TOTAL rewrite... just some major reorganization.

But in either case, it's not planned to go into the official code in any planned release.

There are some very exciting things coming up on the horizon, nevertheless.

scheming up from the day you were interviewed for the job - I remember the graphics Good luck on implementation, would be cool to see

I know what you where saying and how it works. All i am pointing out is, its a good idea in theory, but the ubb in its present form takes up quite a bit of resources, and that is when everything is intergrated, but when you have modules, you will increase the server load.

Not everyone has the luxary of their own server or a powerful one owned by someone else which is just set up for ubb's. We in the real world have servers which maybe shared, or maybe more geared up for sites not using much resources.

No doubt (as you have said), a module structured ubb would be a lot better, hell anything using modules would end up being better, BUT are you telling me in the ubb's present form using flat file format it is even capable with out causing more server load?

Just one last thing, you are saying an intergrated ubb (as is now) or a modulised ubb (as suggested) would not different at all on the server resources and processing it does? I would love for the ubb to be based on modules, but i can't see it being as efficient as the ubb is now.

There would be NO difference in a mudularized UBB vs the current format in terms of loading as NOTHING will have changed in terms of resources required by the base UBB system. There is NO coralation between the two. Your hypothisis has no merrit.

The only time you change this is when you ADD code/functionality to your existing system. And even then much of that is negligable as the current development team of UBBDev is fully aware of this exact issue and code accordingly.

If anything you will only get a tremendous amount of flexability which in turn will allow you to better manage your UBB and resources used. The exact opposite of your claim.

I think Andrew means using the slow Object-Oriented Perl for writing modules.

1) modules don't need to be OO
2) OO perl is no slower (of any significance) than functional perl

Are you sure? I read on 'Object Oriented Perl' By Dr. Conway that OO Perl is actually slower ( to 50% sometimes ) than normal Perl. Probably because Perl wasn't designed to be OO language.