January 21st, 2004:

… let there be code. And there was. But it sucked.

Okay, maybe it doesn’t suck. Regardless, it creates things now. And that’s it. Heh.

So, I’m getting sick of looking at all of this code and not really knowing if I’m going about it the right way. So I’m releasing version 0.0000000001a of Inklog. Wooo.

It does nothing useful. Really. So don’t get all excited and get ready to convert your blog over just yet. However, it does actually do SOMETHING, so if you’re technically inclined, give it a download.

This version of the code is licensed only one way: "You can look and run but you cannot distribute or modify". Like I’ve said before, in the end, most of this will be GPL. But, for the time being, it isn’t. Also, you are not permitted to link directly to the test site, the CVS repository or the Tarball. If you’d like to link to help get the word out, please link to this blog entry. All of these systems and URLs are in a state of flux, and I hate broken links. So please adhere to this small request.

Anonymous CVS scares the hell out of me, because I don’t really know how to get CVS to do what I want and it all seems like a giant hack anyway. So, there is no anonymous CVS. However, you CAN browse the repository. Additionally, since the code is changing so quickly, it’s difficult for me to make a Tarball. However, you can access a current Tarball via the web repository.

So, you’ve downloaded it… what do you do with it? Well, I’ll tell you.

First you’ll need a PHP enabled webserver with PEAR::DB and a MySQL database server. Go get it, I’ll wait. Now you need to get the Smarty release and untar it somewhere on your system.

Okay, now, untar the Tarball into any directory in your webroot. It doesn’t matter where but I suggest using a location that doesn’t have anything else in it, so you can easily delete it when you’re done.

Once untarred, you’ll see a directory called "db". Inside "db" is a file called "mysql.sql". You need to run that against your database. First create a database. Then create a user (or use an existing one). Then type "mysql -u username -p databasename < mysql.sql". It’ll ask for your password. Type it in.

Next copy "config.php-dist" to "config.php" in the directory you untarred in. Then edit "config.php". You just need to change the top two items: "nodepath" and "dsn". "nodepath" should point to the directory you untarred everything in and "dns" should reflect the settings you established for your MySQL database. Save this file.

Now edit "dispatch.php". Set the top three items. The first, "configpath" should point to the directory you untarred in. The second, "addllibpath", should point to the "libs" directory inside of the Smarty install you did. The third, "nodepath", should once again point to the directory you untarred Inklog in. (I know that’s silly to do it twice. Shut up. This is SUPER-ALPHA code.)

Good. Now, type "mkdir templates_c; chmod 777 templates_c" in the directory you untarred Inklog in.

Now, open your web browser and browse to the "dispatch.php" file in the untarred directory. If everything went right, you should see a page called "Main Container CONTAINER". Under it there is a link to "Create PAGE here". Click on it. Type in some stuff on the next screen keeping in mind that "locname" shouldn’t be anything more than letters and numbers (no, I don’t do any error checking yet). Press Submit.

Now browse back to "dispatch.php". You should see your new item listed. Click on it. You should see it displayed.

That’s it.

If you don’t want to go through all of that trouble, you can access the test site I set up. Basically, (test site taken offline) I followed my own instructions, step-by-step to make sure they were correct. Aside from the fact that some people may have added a few things to the database… it should function exactly as it would if it were on your own system.

Enjoy. Heh. Please remember that it’s way super-duper-alpha. It probably opens 14 security holes on your system and renders your webserver as useful as a Windows box.

Comments and suggestions are ALWAYS appreciated.

The hardest most dreadful part of Inklog is upon me: theming. I’ve got the majority of the theming code done. But every half hour that I work on it, I change it to an entirely different structure. I’m stuck in a hole in between flexibility and ease of use.

For instance, when writing the image gallery code, do I want to force users to use gallery?page=4 to signify the 4th page? Or do I want to allow them to use that or gallery/4 to signify the 4th page? What if the user speaks Spanish and she prefers gallery?pagina=4? I can allow just one option very easily. However, a very picky user will complain, and, perhaps, alter the code to do it her way. However, once the code is altered in this fashion, I’ll be reluctant to take any patches or code modification from them because they’ll be using a different starting code base than the "official" code is. Perhaps I should allow the page identifier to be specified in the configuration? This way a user can say "my page parameter is named ‘pagina’, while another user might use ‘page’, while another user might use something entirely different. I can give this level of flexibility, it just means a lot more work. I can also skip all the extra work by placing the role of deciphering which page to display on the template itself. This makes the template code more complicated but much more flexible.

If everything is stored in configuration, then the next and previous page URLs can be generated for the template instead of forcing the user to piece them together herself in the template code. One big problem with generating URLs for the template is that the URLs will be specific to a transport type (HTTP, for example). The "URL" to transport that item via XML-RPC or via SMTP might look entirely different and, at that point in the code base, the renderer doesn’t know what medium it’s being rendered for, and it shouldn’t have to. I could use an "internal" URL to the document and then have the template author run the URL through the modifier of their choice to produce the correct URL, but then the modifier will have to know a little something about the transport layer and its designed URLs. I had hoped that the transport layer would be simple to code and ultimately flexible allowing greater use by more people. This would complicate matters considerably.

I think that I’d like to use a combination of the above. Perhaps I’ll still hold the page identifier (and other things) in configuration, and, using this data, I can auto-determine how many items to retrieve, and where to begin based on the page identifier. However, I wont construct a nextURL or a previousURL for the template. Instead, I’ll provide the template with a nextPAGE and a prevPAGE and allow the template design to construct the URLs appropriate for the system.

I think.

It’s all too confusing. There are a million options and none of them are any more "right" or "wrong" than the others. The system is flexible enough that changing something like this after it has been written won’t be too difficult. Especially if I don’t have to retain backwards compatibility with the old way of doing it. Therefore, it might make the most sense to just pick one (perhaps the easiest to code that retains the most flexibility) and then, after beta testing take suggestions and rewrite it if needed. I think that’s what I’ll do.

Once again, however, and comments or suggestions you might have will be greatly appreciated.