Hi!
Maybe you can add the built in DB support. I think MySQL will be ok but with PDO is easy to develop every DB. I have class to use database but it's external thing and it tooks few lines to much I think.

In 0.3.1 or 0.4 it can be done. I think, the DB support and full support for multi-host is the last thing needed now in PRISM to make it the best.

Yeah, I have no problem with this. I'm just into locking down the basics that will work on all systems. Right now, PRISM does not require any modules to be loaded in order for it to run, and I mean that you can take the php-cli.exe and just use that to run PRISM. That also makes PRISM very portable, but I do agree that doing some database work would be a nice step up for PRISM, however I would not expect it for a while as the core is still going though changes. Anything past 0.5.0 is pretty much feature lockdown, but there is going to be a huge update for 0.7.0, so I would expect that you'll see PDO / MySQL(i) support in that. Personally, I like MySQLi better, never used PDO but I like that fact that it works with everything so I'm quite happy to use that too.

I think there can be built in singleton(single instace of class in Polish - I don't know how to say it in English?) for DB.

I personally prefer PDO because it support's every database system (most popular of course).

You say about huge update. If PRISM is going to be an PHP InSim system it has a lot of basic, required functionalities and I think, it don't need too much (buttons, gui tables), to be done as PHP InSim.

Quote from misiek08 :

I think there can be built in singleton.

That's correct in both English and Polish. I tend to agree that any database access that happens should be both persistent, and singleton in an application environment.

Quote from misiek08 :

I personally prefer PDO because it support's every database system (most popular of course).

And I agree with that too, I think PDO will be the final choice. I just hope it's close to MySQLi as I love that style interface.

Quote from misiek08 :

You say about huge update. If PRISM is going to be an PHP InSim system it has a lot of basic, required functionalities and I think, it don't need too much (buttons, gui tables), to be done as PHP InSim.

Not really sure what you mean here so I'll continue the party line. PRISM is meant for people who are just starting to program and have an interest in the Live For Speed InSim system, giving you an API and SDK at the same to for programmers new and old. I also feel that PRISM should be portable, I for example intend to run this on my WRT610N router when I'm done with it so it's always on. It should also be easy to use, giving people a chat command interface, a button interface, a web interface, and a telnet interface so you have flexibility of interface and can thus admin your server much easier. PRISM has becomes very much like the Metamod and AMX Mod for PRISM and that's exactly what I wanted it to be and I can't thank Victor enough for giving me such help doing it.

Ok. Now I understand.

It's great idea.

Thanks for this what is done. I saw a new part of using __call(). It's great example. I know PHP only by reading others people codes. The PHPInSim Mod was written not good way. I've rewritten it. Now if the PRISM will have DB support before start of November I'll use it. If not: I will make PHPInSim easier to use. I started making AJAX live data from LFS but on PHPInSim Mod.
Now I'm waiting. If you'll add the support for MySQL I'll make a plugin for PRISM.

Quote from misiek08 :

Ok. Now I understand.

It's great idea.

Thanks for this what is done. I saw a new part of using __call(). It's great example. I know PHP only by reading others people codes. The PHPInSim Mod was written not good way. I've rewritten it. Now if the PRISM will have DB support before start of November I'll use it. If not: I will make PHPInSim easier to use. I started making AJAX live data from LFS but on PHPInSim Mod.
Now I'm waiting. If you'll add the support for MySQL I'll make a plugin for PRISM.

It might happen by then, it might not. If I can come up with a single way to handle both the flat file interface and the database interface then sure I'll add it sooner, or you could add it yourself if you feel the need.