I won\’t mention anymore than this: but I\’m starting a topic called sunfox. Sunfox.net is the new version of OXWAF that will be designed for single site use, easy to install, and include all the features of oxwaf in a fairly fast, compatible way.
That said, I want to start talking about it here to get comments about it\’s individual components. It will be public software, so I\’m not overly worried about others having or making use of the source code. If you want to take a look at the source code visit:
So let\’s start with the first major design decision that was made with this version that we didn\’t do with OXWAF.
Major Decision Decision 1)
Everything except the main driver file (index.php), and the config file, (conf.php) shall be classed. But more so, every one of those classes should be able to be extended or replaced by a custom created class. So for example, this is the first 2 lines of index.php:
include \"conf/config.php\";
include $GLOBALS[\’SITE_PATHS\’][\’mysql\’];
So as you can see, the conf file is included straight, but the include of the mysql class is actually a global variable in the SITE_PATHS. These values are all defined by default at the bottom of the conf file with a notice saying that you don\’t need to update those lines unless you really know what you were doing.
So does this sound like a good idea? Should users be able to extend or replace any feature? It gives them the benefits of being able to say, replace the msyql driver with a postegre driver. They could even replace the virtual addressing if for some reason they thought the system was not worth while. The only downside I can think of is that people could try to do things and break the entire system, or introduce bugs that were never ment to be there…
I don\’t think that\’s a big issue though. If they do it, it\’s their fault.
Ok, so that\’s my spiel on that decision… let\’s talk about the two classes that are in place, and doing something already (at sunfox.rinsefirst.com).
Mysql Class:
This is almost identical to one we had in oxwaf, except some minor changes to improve the sql syntax where possible. The goal will be to not use the query function at all, but instead stick to select and insert functions. This way, at some point, in theory you can have as many mysql servers as you want (replication) in order to speed everything up, while only having 1 insert server (the main server).
Virtual Address Class:
This to is almost identical to the oxwaf virtual address class, except for few very key things.
1) I\’ve added the ability for wildcard folders. Something dan had requested and I thought was added into OXWAF, but it doesn\’t look like it.
2) I\’ve removed the the file system class for the moment. This is the only file I believe that was used, and it was used for only one function. I might be wrong, but until we run into a need for more file system stuff, I\’m going to leave it like this. It should be noted though that this is what I did.
3) I\’ve made sure to put the matching in the order they are likely to happen to help speed up filename matching (this was pretty minor).
4) Lastly: It no longer returns the page itself… IE: it doesn\’t make the calls to the blueprint engine. It doesn\’t try to figure out what type of file it is. It does remember what the data_id and data_type is so that another class (not yet developed) can handle the data processing. I\’m not sure why this abstraction was not in Oxwaf… Maybe it just never made sense there…
So that\’s my speil on that.
Feel free to post questions about sunfox while it\’s under development. I\’m sure we\’ll start posting design debates soon (mainly about security). If you want to see the files as they are in sunfox, please checkout cvs.sunfox.net
Thats my speil on sunfox for today.. Enjoy… Oh and Nebraska barely won… yay.
Comments on this entry are closed.
From looking at the code and previous discussions…
It might be a good idea to start making this stuff less vendor specifc. You have said it yourself in the ldap discussions before that we shouldn't have to depend on mysql etc.
So i think a good start might be to replace Mysql_DB class with some sort of other thing like Data_Source or something. Then, from the config, we know we are using mysql and then carry on from there.
Perhaps even in the config the name of the class is defined.
$GLOBLAS['settings']['data_source_class ']= 'Mysql_DB';
and then
when we need stuff we can just use the standard CRUD commands that are already sorta present inside of the Mysql class.
If we need to change the database (or maybe even use something else, like… xml?) then we can just point it at a new class and… viola.
Just a thought. Looking good so far.
it was the ldap issue that i was thinking of when i did the include $GLOBALS['SITE_PATHS']['mysql'] and not just including mysql… It makes more sense to label this ['date_source_class'] though if the idea is that someone could change it to another type.
It would be simple to put a class that mysql actually ends to perform the data transfer. I do not think we should have an inbetween data type though (such as mysql). I don't want to turn something that should be a simple task (such as virtual host lookup) into a larger task because we had to convert from virtual host language to xml to mysql to xml and back to the virtual host.
What I'm really wondering is if it's wrong to assume that the user wants to emulate the mysql functionality and/or only replace the things that they didn't want mysql for (IE: ldap for the user authentication class, which doesn't exist).
It's not the create, read, update, or delete that I have a problem with… It's the speed of the where.