I don't see the point of implementing an own PDO-like interface, since PDO is fast enough, feature rich and imho is the future of low level DB abstraction in PHP. A higher level abstraction (eg. ORMs) is too complex and slow for such an application.
About the persistent connections... I think you should not use keepalives. Just reconnect again if connection is lost. The only time penalty is present when you have to use some remote TCP/IP connections but typically the databases run localhost. Using unix domain sockects provide quasi immediate connections. Anyway, extending PDO leaves space for implementing keepalives if you wish to.

Quote from Dygear :

If anyone has any ideas I'm willing to listen.

You don't have to go one-size-fits-all. Novice users aren't going to use advanced database features anyway and would probably prefer something simple like DarkTimes suggested. PDO singleton idea would be a good solution for advanced users.

Also keep in mind you don't have to add all these things to the PRISM core. If PRISM is an engine that runs plugins and these plugins can talk to each other ...

I'm starting to use PDO a little bit more now. It's not so bad when it's coupled with SQLite, just takes some getting used too. Not everything works as you would expect, some things work much better, some things work much worse. But I think as long as people have their php cli setup correctly it should be ok. That said, I'm not thrilled with the idea that PRISM will now require a module in order to use database functions, but we might as well make it PDO as it's pretty lite, and it comes with SQLite!

That said, SQLite is pretty amazing all by it's self. It's powerful enough for it to be used by the core of PRISM, but it's easy enough that anyone can use it. I've only been programming with it for the past like 30 minutes, but I'm already impressed. I think that this will be perfect for anything that any of the guys out there will come up with. It's powerful enough, but lite enough, it's the goldilocks of database design.

Quote from Dygear :

It feels like that's the easy way out. It would be, but I don't think that's fair to the people who started using PRISM. I will get PDO support I just have to think of a good way to impalement it so it's not insane for everyone. I think I have a lot of programming ahead of me.

I don't consider it the easy way out, more an acknowledgement that anything you write will be generic (by requirements) and won't be honed for any kind of specific purpose. Also your forcing developers into writing against whatever you think is best, which may not suit what they're trying to do. For instance I'm sure most PHP developers are quite happy writing SQL queries, whereas I would much rather find a nice ORM layer to use. And as filur says, if plugins can talk to each other, then what's to stop you having different plugins for different database systems.

Also the idea of storing key/value pairs and serializing objects isn't that daft. I mean, that's how World of Warcraft addons do it. I've no idea what PHP's object serializer is like, but being a dynamic language I'm guessing it's probably pretty good.

Concentrating on the wrong thing I think.

There is not even a friendly / intuitive UserInterface.

Quote from cargame.nl :

Concentrating on the wrong thing I think.

There is not even a friendly / intuitive UserInterface.

What would you like to see?

Quote from DarkTimes :

And as filur says, if plugins can talk to each other, then what's to stop you having different plugins for different database systems.

I was thinking about this, and thinking about this, and thinking about this. I'm going to use the same sort of solution we use for connection mangers. Where, you can start a connection, PRISM will hold on to that connection for the life of the application and then you can setup permissions from a plugin interface (GUI -- For example from buttons in game, or from the Web GUI) or you can do it from the config files like in the same way that you setup a plugin to be able to use a InSim connection. It should be pretty interesting. The problem is programing it, getting around the logic so you don't step on anyones toes.

Quote from Dygear :

What would you like to see?

Well...

A basic example of creating and removing buttons could be a start.

Like an information window based on buttons and that if you click on the window that it will remove itself.. And/or, when a race restart or race end takes place. I am missing this kind of basic procedures

I respect the work you already have done and your study though. Don't get me wrong!

Quote from cargame.nl :

Well...

A basic example of creating and removing buttons could be a start.

So you want more of a Programming API introduction. Ok, the only problem with that is that I'm not sure that the API is done quite yet. Some things could change, and if I do change something it's going to break the documentation that I do make, making me have to make the documentation twice, or even three times. But if I do have the time, I'll be sure to write up some documentation on what I have right now, and I'll hope that I won't have to change it later. (Program the interface once and for good, will by my motto.)

Quote from cargame.nl :

Like an information window based on buttons and that if you click on the window that it will remove itself.. And/or, when a race restart or race end takes place. I am missing this kind of basic procedures

Not really sure what you mean by an Information Window. Do you mean a set of buttons that are used to act as a window interface for PRISM in the same vein as that of a Input Prompt for Windows? Do you mean like this:?



And then your asking how to make this in InSim?

Quote from cargame.nl :

I respect the work you already have done and your study though. Don't get me wrong!

Thank you, I appreciate that and I hope that you stick with the project because I love your servers and I think it would be great to have PRISM running on a server that I go to often.

Just coded a VERY simple cruise app using PRISM, due to my main server is offline at the moment due to the datacentre. People kept pestering me to get something online so I made a very quick app using PRISM.

Stability seems very nice .

Now time to code the race system

Quote from Dygear :

Not really sure what you mean by an Information Window. Do you mean a set of buttons that are used to act as a window interface for PRISM in the same vein as that of a Input Prompt for Windows? Do you mean like this:?

Hmm something like this... [attachment]

I want be able to show information from my MySQL database in LFS and I have like zero InSim programming knowledge. No idea how to design this with PRISM.

Also note the line at the bottom. Click to make the window disappear and you can even switch to a next page if available.

Quote from cargame.nl :

Hmm something like this... [attachment]

I want be able to show information from my MySQL database in LFS and I have like zero InSim programming knowledge. No idea how to design this with PRISM.

Also note the line at the bottom. Click to make the window disappear and you can even switch to a next page if available.

You mean to tell me you made that without knowing how to program for InSim? I've got to see your backend to get an idea of the kind of interface you want.

[Edit] I just figured it out, it takes 52 buttons to make that interface. That's 1/5th the allotment of buttons for a UI area. Still, how you designed that I have no idea. No idea how to make a WYSIWYG editor for PRISM buttons.

Quote from Krammeh :

People kept pestering me to get something online so I made a very quick app using PRISM.

Stability seems very nice .

Glad PRISM allowed you to do something quickly, and two thank god the Stability is awesome. Me & Vic worked pretty hard on that part. (Unit testing was really his forte, but I gave it a shot from time to time.)

Ehrm thats Airio, Dygear

Quote from cargame.nl :

Ehrm thats Airio, Dygear

I know, but ... but then you did not make it right? Your just using an element provided by Airio. Or did you some how set that up from a config file?

It's just one of the many build in screens (!pi racername).

Quote from cargame.nl :

It's just one of the many build in screens (!pi racername).

Ok, so you did not make it, it was already part of the interface. Yeah, that won't be a problem.

Quote from Dygear :

Ok, so you did not make it, it was already part of the interface. Yeah, that won't be a problem.

as far as I know it works in the way that you were planning to implement the menu's. Give it a title, list content, and have prev/next buttons. Much like the SOURCE menu system.

Quote from Krammeh :

as far as I know it works in the way that you were planning to implement the menu's. Give it a title, list content, and have prev/next buttons. Much like the SOURCE menu system.

Exactly! (By the way first post from a ChromiumOS device, just installed Chromium on a USB drive, and damn this thing is quick, even from the USB drive.)

They released a version of it now?

ps. each plugin, does it run in its own space for each server? ie if I use the same variables/arrays, will they be separate from server1s variables to server2s variables?

Quote from Krammeh :

They released a version of it now?

ps. each plugin, does it run in its own space for each server? ie if I use the same variables/arrays, will they be separate from server1s variables to server2s variables?

No, PRISM is just a traffic cop in this case, the memory of the plugin is handled by the plugin. So when you sign up a plugin to get packets from a server, it get's all requested packets from that server. If a plugin is signed up for two servers, it get's all packets signed up for from both servers. The state information will have to be handled by your plugin.

Although that's a pretty interesting idea, instancing out a plugin on a per connection basis. The only problem with that would be that some people will want to offer intra-server communication and the best way to do that is to let the plugin handle it's own variables and memory space at the plugin level.

As filur raised before, there is no reason for this to be part of PRISM's core, it could be a plugin... or a module... or an addon, I'm not quite clear where the distinction lies with PRISM

Quote from morpha :

As filur raised before, there is no reason for this to be part of PRISM's core, it could be a plugin... or a module... or an addon, I'm not quite clear where the distinction lies with PRISM

Core

Any code that is required for initalization or startup of PRISM.

Modules

Any code that can be used my multiple plugins concurrently, or code that provides a direct interface back to the core from a source outside of the provided InSim packet interface.

Plugins

Any code that uses the InSim packet interface or that does not meet the above qualifications for a module.

Simple enough?

Quote from Dygear :

No, PRISM is just a traffic cop in this case, the memory of the plugin is handled by the plugin. So when you sign up a plugin to get packets from a server, it get's all requested packets from that server. If a plugin is signed up for two servers, it get's all packets signed up for from both servers. The state information will have to be handled by your plugin.

Although that's a pretty interesting idea, instancing out a plugin on a per connection basis. The only problem with that would be that some people will want to offer intra-server communication and the best way to do that is to let the plugin handle it's own variables and memory space at the plugin level.

There a function/variable to find out which server a packet comes from?

Quote from Krammeh :

There a function/variable to find out which server a packet comes from?

Yes, it's called curHostID in the HostHandler class. You can access that from your plugin via $PRISM->hosts->getCurrentHost(); This will tell you what hosts has sent the packet your currently processing.

Don't call the HostHandler::curHostID directly, because it's name is going to change in the next version to it's proper name of currentHostAlias. The $PRISM->hosts->getCurrentHost(); function will remain the same so it is safe to use that still, as that's the most correct name for it. (It's not really an ID, it's an Alias for the server, the same as you entered for your server when you setup that connection.)

That makes sense! Thank you .

Not had a single crash (That wasn't typo related in the plugin :P), Thanks.