I’ve setup a temporary location for InkLog CVS access. The server location for this will change when I finally find a place to put all of this stuff permanently, so don’t get too attached to these locations. However, for the interested, you can browse the InkLog code via the temporary Web Based CVS viewer. It’s running of my DSL at home with a Dynamic IP address. So, if it’s down, try again in 15 minutes. The web interface will let you download tarballs. If you’re interested in an actual CVS checkout, the following should work:
cvs -d:pserver:anonymous@revjim.homeip.net:/var/lib/cvs co inklog
For those of you that do choose to browse, you should know a few things. Under include/smarty/ you’ll find the Smarty Libraries. I haven’t changed anything there and my only addition is at includes/smarty/plugins/resource.inklog.php. I’m sure I’ll move that file into another location soon, in order to keep the Smarty libs in their natural state (Update: I’ve moved resource.inklog.php into its own location). Additionally, the current dispatcher expects dispatch.php to be called via HTTP. It looks at PATH_INFO to find the node that is being requested. Using mod_rewrite or an ErrorDocument 404 is the best way to get dispatch.php OUT of the URL. This is all written in modular fashion so if someone doesn’t like how the dispatcher works, it can be changed.
The core node functionality is there. There is no install script. There is no managment interface. There is no documentation. There are also no modules to provide any of the useful behaviors. This means that, at best, with a lot of patience and a MySQL client, one could force it to serve very simple text and html, but not much more.
Before I add modules to handle the more interesting functionality, I need to have a mangement interface. And before that can exist, I need a permissions module. So, that’s next on the list. Additionally, the data conversion framework has not been written, which will be needed before the modules can really do anything interesting. So, needless to say, there’s still a lot of work to be done.
I’m not quite sure how to build the permissions framework. I could put permissions on the nodes alone, and have the controller check permissions before calling the model. That’s the cleanest way to do it, but also the most featureless. I could implement it in the views, as that would provide the most flexibility. However, that is also the most security-bug prone method. Maybe a hybrid of both? I’m not quite sure yet, but I’m open to ideas.
The Config framework also needs to be written. Most likely before any modules are, because the modules I write will most likely need the config framework.
So, for the near future, the order of my development is something like this: permissions framework, conversion framework, config framework, management interface, and then the first module.
Let me know what you think.