PHP4 sessions, even as an option?

[dahamsta]

PHP4 sessions seem to have been discussed a few times, but I don't think the subject is getting the attention it deserves. It appears that the developers aren't very keen on them, and that's fine, but I would be interested to know if there is demand for them?

I'm talking of course about the automatic session handling in PHP4, which has matured - I don't think they're even working on it anymore, which says a lot. I for one would very much appreciate even the option of using PHP4 sessions instead of the inbuilt vBulletin session manager. (You know, one more switch in the control panel? :)) Would this be prohibitive?

My reasoning is simple, I think the core of vBulletin is very professional, and like many I'd like to use the core as a base for the rest of my site. Without "API" documentation that is very difficult, but using the inbuilt PHP4 session handler would make it a bit easier for a start.

That said, I'd much prefer the aforementioned "API" documentation. A simple layout of how vBulletin works and how to replicate sessions and permissions in in-house code would be bloody handy. (Course, I'd prefer both... :))

Again, I'd be interested in other users opinions on this. I'm not saying "vBulletin *has* to implement PHP4 sessions" - that would be stupid - I'm more interested in whether people feel the same as me about the subject.

adam

[Freddie Bingham]

We have discussed dropping the session code we created and supporting the built in session support of PHP4. There has been no firm answers though as to what we are going to do in that regard.

[ethank]

Originally posted by freddie
We have discussed dropping the session code we created and supporting the built in session support of PHP4. There has been no firm answers though as to what we are going to do in that regard.

What would the benefits be of using PHP4 sessions? We built off VBulletin for our site with no problems, and the session code is pretty simple to figure out with some digging.

That being said, some better docs on the chain of includes would be nice :)

Ethan

[Raz Meister]

The built-in sessions for PHP may be faster as its complied into php.

[dahamsta]

Actually they would be faster, as it requires no actual PHP code at run-time. Also, the default method for inbuilt PHP4 sessions is to use the filesystem for storage (this can be changed of course) which is faster than a query to the database. That's not the main advantage though...

When PHP4 is compiled --with-trans-sid and session.use_trans_sid is enabled, session management is handled internally and transparently by PHP. You don't have to worry about appending the session ID to the URL, or adding it into your forms, PHP automatically rewrites the HTML before it outputs it.

All you have to worry about is starting sessions and storing your variables. The only way to replicate this currently in vBulletin is to use the output buffering functions, and this would be quite complex.

adam

[xshredx]

how about using another sessions codebase (phplib and PEAR come to mind)
this would really be a great thing:: as it would allow for much easier integration in existing websites...
that's my biggest problem i have with vbulletin and most of the other msgboard software: there has not been put enough thought on the integration-into-site aspect...

i don't really care about the speed gain from going to native php4 sessions... i don't think it will be noticeable...

but i would really want to have something like phplib used for vbulletin: since this is an excellent code base for website development (i use it), but also for people that make sites that don't use something like phplib... these classes are much easier to integrate (subclass it a bit..) in a site than the vbulletin sessions system... (not speaking about a permissions system site-wide or so...)

so i would want to ask that you consider a move like this instead of going to native php4 sessions...
if it were only the sessions and authentication and permissions + user code from phplib (i don't even ask for a database-abstraction layer, or the use of the phplib template parser)

this would be a true and superb move for integration of a message board into a site.... and as i see it now, i prefer not to use the vbulletin core for any of my site development.. no offense but compared to something like phplib... well....

and again, i have my doubts about real noticeable speed differences if native php4 sessions would be used.... msgboard software can be so intensive (also database-wise) that that little bit of sessions code does not make a real difference...

do some move like this, and i instantly buy some vbulletin licenses... i would really love that, and i know most of your existing customers would feel like me... how easier a forum can be integrated into the other parts of a site, how better it is...

[dahamsta]

I don't think moving to phplib would be a very good idea at this stage. I don't deny that it's a good app, but PEAR is going to all but kill it off in time. The DB classes are already pretty mature, and the development of PEAR is running at a fantastic pace.

As to speed, the fact that vBulletin is forum software makes it all the more important to cut PHP code as much as possible. The vBulletin developers have done a fantastic job here, but knocking off a few more milliseconds would be a boon to large forums.

adam

PS. Thanks for all the replies BTW. I thought I'd get more of a response here to be honest, I'm surprised more people wouldn't like to see this, particularly the API documentation.

[xshredx]

i don't really care so much if they would use phplib or PEAR... i just wished vbulletin was made with an API that's easy to use, easy to extend, and that's really solid and fast running... and that's what i find in the phplib.... not only the database abstraction layer (most people have no need for one, surely not a very advanced one), but also the sessions management and the user and perm classes, the template parser...............
i also like PEAR, no problem... i just want a decent API that's all... that would be a real improvement to vbulletin...

and i don't say that a speed improvement, also a little one, is not very nice, but the stuff also still needs to be usefull... and that's where vbulletin does not shine i think... not easy enough to integrate in a site, i cannot stress this enough...

and speed improvements from switching to native php sessions was where on i reacted and said that this will not mather that much...

the real speed improvements come from good, fast queries (as less queries as possible), and vbulletin is good in this aspect... what i want to say is that all the code for a message board is there in every forum... all msgboard software needs to do the message formatting, building the pages, and whatever more...
a real usefull API like phplib or PEAR will be no speed breaker i think... and that's why i don't see any arguments against putting one in vbulletin...

i also don't think the vbulletin developers aren't capable of designing an own one, but 1) it will take them some time to make it as good, solid, fast, and still usefull and easy as phplib, pear...
2) why reinvent the wheel, if there are already a lot of people working with these API's, and there is also a lot of information about it...

and yes, it's a pitty there is very little discussion regarding this matter... unbelievable...

[JamesUS]

phpLib/Pear sessions aren't going to happen. We will either use a homegrown solution (what we have now), or PHP4's built in session code.

We can't legally use phpLib sessions because they're open source, so we wouldn't be allowed to sell a product containing them.

We are planning easier ways to integrate vBulletin with other products and applications...however they will not be ready for a while.

[dahamsta]

phpLib/Pear sessions aren't going to happen. We will either use a homegrown solution (what we have now), or PHP4's built in session code.

I'd prefer the inbuilt meself anyway. The previously legitimate claims of instability and security issues no longer apply anyway.

We can't legally use phpLib sessions because they're open source, so we wouldn't be allowed to sell a product containing them.

Ah, I didn't think of that. I wonder would the same apply with PEAR, since you're "linking"? Course, vBulletin should be GPL'd anyway, and sold as a service. But that's another debate... :)

We are planning easier ways to integrate vBulletin with other products and applications...however they will not be ready for a while.

Pity, but it's great to hear you're working on it. I'm developing my own product at the moment for example, a medium-level CMS and site manager, and I'd love to build in hooks for vBulletin.

Thanks for the reply.

adam

[xshredx]

as far as i know, it is perfectly possible to use phplib that is open-source in your commercial software...

and pear would be possible too i think... and i stand behind dahamsta with his vbulletin versus gpl point of view...

and about the homegrown solution: nice, but, no offense, till you people have an API that is as sofisticated as phplib or PEAR..... well, i wanne see it first... i hope you people can come up with something really usefull, easy and solid for integrating vbulletin in a site... good luck with it!

[JamesUS]

We cannot 'sell' in any form an open source product, and pear/phplib is open source. Including it in our product and selling the product is illegal.

We will never use phpLib or Pear sessions, templates or whatever in our code. As I previously stated, we will either use solutions built into PHP, or homegrown solutions like what we have now.

[dahamsta]

We cannot 'sell' in any form an open source product, and pear/phplib is open source. Including it in our product and selling the product is illegal.

No, it's absolutely not. You can sell it all you want, you just have to ensure that the source is made available free of charge. That might seem odd, but MySQL still makes a fair few bob (understatement) out of their GPL-licenced Open Source product, from installation and support. MySQL also sell a commercial product released under a different licence.

An even better example is Gossamer Threads, who came to fame through their Perl products. dbMan and Links are available for free download, and a lot of people didn't pay for them - which was actually a breach of their licence. But they never chased people down, because: 1) their open code led to huge improvements in the products, including tons of hacks; and 2) people who used the product commercially actually /did/ pay for it.

Now they have more complex SQL-based products, which aren't available for free download, but the community is still there. And they sell lots of services, like bundled hosting. But to come back to the topic in hand, the suggestion that you can't sell GPL'd applications is a complete myth. And on top of that, the legality of "linking" with PEAR and phplib is an area that has never been proved. I think they only way to sort this out is to talk to the relevant groups and ask them to clarify their licence.

http://www.opensource.org/advocacy/case_for_business.html

adam

[JamesUS]

From what I understand the only way to do that would be to make our source code publicly downloadable - something that is certainly not going to happen.

Regardless, we will always use a homegrown solution wherever possible, rather than bring in scripts other people have written.

[dahamsta]

From what I understand the only way to do that would be to make our source code publicly downloadable - something that is certainly not going to happen.

Why not? Afraid you can't make it as a services company? :)

Seriously, I'm mostly just kidding around here. Some people want to do it open source, some people don't, that's their decision, and I respect that. And I'm certainly not qualified to argue about open source with you[1], because I sometimes have difficulties understanding it myself. Particularly when it comes to scripting languages, as opposed to compiled languages, a topic that has come up many times in the past (on /. for example), and doesn't seem to have ever been clearly resolved.

However, that's all moot, we've drifted off-topic, because the topic as I started it here is about the use of inbuilt PHP4 sessions and/or a documented vBulletin API, which I think are sorely lacking, because it would appear to me that a lot of people want to use vBulletin as the core of their site. (And in my own case, our products, including licencing agreements if they can be arranged.)

You say you're working on them, and that's cool, but I just want to stress how important it is, not only from the site administrators point of view, but from Jelsoft's point of view. In my view, documenting the vBulletin API and making it easier to integrate will boost market share. You'll be another step up the ladder from the UBB.

Regardless, we will always use a homegrown solution wherever possible, rather than bring in scripts other people have written.

And that's cool too. That's the reason I'm writing my own CMS and site manager from scratch - because I don't like what's available. But in a way, I've learned from vBulletin, in that I know that if I want to grab market share, I have to make it independant - it all runs through one class - and easy to integrate - I'm documenting the API.

See, I'm not trying to start a flame war, I'm trying to help. :)

adam

[1] Maybe we can get RMS or his gun-tonin' loony friend in here!

[JamesUS]

See, I'm not trying to start a flame war, I'm trying to help. :)


Glad to hear it :)

We have been discussing ways to make it easier to integrate vB into other products; discussions along these lines have featured in our last few development meetings. Ideally we'll have something in for the next major release. However, as I'm sure you'll appreciate, it's not easy to come up with a great and easy to use API. But rest assured we'll be working on something.