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:
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).
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.