revjim.net

After ranting about not knowing exactly what Syntax is, I realized something: I've never really stated exactly what Inklog is. So, here goes.

First and foremost, don't infer any meaning from Inklog's name. It was named that before it became what it is (will be) today. In fact, it needs a new name. If you've got an idea, let me know.

In order to describe what Inklog does, it's easiest to describe a scenario and how it would work with and without Inklog. So, let's start with a weblogging application since it was the reason Inklog was started in the first place. At the bare minimum, to write a weblog application you need 3 things: a place to put the data, a way to read the data, and a way to add data to it. Everything else is just "features".

So, without Inklog, our first step would be to decide where to put the data. Let's say we'll put it in a database. Great. So we design a table to hold the data and put it on a server. Now we need to be able to add data to it. So, we write a small script that presents a HTML form to the user and, when receiving input, shoves it in the database. We'll call this script "edit.php". Now, to read data we need a script that will access the data from the database and display it in a pretty fashion. We'll call this script "read.php". We write it and we're done. Now we have a simple weblogging application.

At this point, using Inklog isn't really that advantageous. I mean, these scripts are pretty simple, why bother with learning an entire application framework just for that? But then things change. You'd like your weblogging application to have "permalinks". You know, those nice little pages that show one, and only one, of the pieces of data that you've entered and reference it in such a fashion that it'll be usable over and over again. No problem, that's just another script. We write it and name it "one.php".

Then we decide we'd like comments on our weblog. Okay, we add another table to the database to hold comments. Then we write a script to add a comment, "commentadd.php", and alter our "one.php" script to show those comments. Easy as pie.

Then we decide that we'd like a photo gallery on our site. We create another table in the database to hold the photographs. We create a script to display the photographs ("photoshow.php"), and another script to allow us to add new ones ("photoadd.php"). Great.

Now we'd like to let other people write blog entries in our blog and add photos to our gallery. But we want to know who's doing what and we don't trust people to always specify the correct name. So we write an authentication script, add a table to the database to hold the users and then we edit "edit.php" and "photoadd.php" to use the new interface. We also create a script to let people log in and call it "login.php".

At this point, the application is getting more and more complex. The photographs code is tied in to the blogging code a bit through the authentication code. Still, without Inklog, things are too bad… yet.

Now we'd like to allow comments on our photographs. Hmmm… do we make another table for photograph comments and alter our exiting comments scripts and photographs scripts to use that table, or do we use the same comments table? Let's use the same one. We alter all the scripts that read or add comments to allow us to denote what kind of comment it is so that we don't have to change the ID numbering scheme we were using before. Then we add "photocommentadd.php" and "photocommentview.php" to our existing array of scripts.

Cool. Now we'd like to have an RSS feed of our blog. Easy as pie. "rss.php" is created and we're done.

Now we'd like to integrate updates to our photo gallery in the RSS feed for our website so that RSS readers will know when either updates from the same feed. Huh? That's hard work. Okay… we write a script to gather data from both sources, then compare the dates from the two and arrange them in order and shoot them out the other end. This isn't easy but, eventually we do it.

Then we decide we want the comments in the feed too, and we want to be able to alter the look of our site be editing one file, and we want to be able to share the code with someone else, and they don't want comments on their photographs but they do want them on blog entries, and then we want to add trackback and pingback and ATOM. And a nice Blogger.API to the blog section. And we want our static website to share the same look and feel as our blog and gallery and….

ENOUGH!!

With Inklog… this is all easy. Inklog takes a single principal and blows it out of proportion: in most cases, all people really want to do with any website (blog, gallery, FAQ, discussion forums, static site, etc) is store a arbitrary chunks of data in a hierarchy and retrieve those chunks in arbitrary conditions and they want to do it all in a way that allows their site to have a consistent look and feel.

We all understand the simplicity of hosting an image, or an MP3 file, or even an HTML page. We stick the page on our web-server and people access it. The problem is, there isn't a "blog" file type, or a "comment" file type, or a "photograph" file type and even if there were, the server doesn't easily allow random, possibly untrusted people to add content of their own (comments, etc). Even if those file types existed and we found an easy way to add in good authentication and methods to allow random users to upload various chunks of data to various places, we'd still have to get all these users to install software that can read each of these file types. And, to make things worse, we'd still have to write methods of creating those file types.

Inklog allows users to store ANY type of data in it. Each piece of data has an associated type. However, instead of forcing the user to install software that allows them to read these pieces of data and create these pieces of data, we do that on the server to. So, for each type of data that is stored, a module is created that knows how to convert that data type into a format that our users can use: HTML, text, XML-RPC, RSS, whatever. When you ask for a document, you ask for it in a specific format. Inklog then gets it, converts it, and gives it to you. So, if you have an MP3 on your site, and a user asks for it as HTML, then you can show them a nice pretty page describing the MP3, showing a transcription of the MP3 and a link to actually listen to it. If they ask for an MP3 as an MP3, then you just give it to them. And Inklog takes care of all of this.

You want comments? Great, write a module that knows how to read a comment. create a comment and convert a comment into a few popular formats. Now, all you have to do is give users permission to create comment objects inside of blog objects, and all your blog entries are comment-able. Want it for photographs too? Fine, give them permission to create comment objects on photograph objects and you're done. Want to restrict a certain entry from getting comments, just deny that permission on that blog entry. Done.

Everything locks together. Everything knows at least basic information about everything else. Everything looks the same unless you ask it not to. Everything just makes sense. Now, when you take a new picture, or record a new song, you don't have to make a HTML page for it that links to it, then write a blog entry that links to the HTML page, then upload the song or picture, then the HTML page, then publish the blog entry. You simply upload the song or picture, and you're done. If you want to write a description for it, fine. If you want to disable (or enable) comments on it, fine. Whatever you want. It's all easy.

You want a Moblog script? Great, make an email alias point to a program that dissects an email message. Send the text of the email message to the system as a "blog" object using the Subject of the message as its title. Then send the attachments to the server as objects inside of the "blog" object. That's it. And all of this is done through an easy as pie API. You don't have to learn database structure, or manage usernames and passwords for things, or deal with rebuilding your indexes, or any of that mess.

You have a group of visitors that want to be notified via email whenever you update your site? Cool… write an email output module, and add a "new object" hook to the root of your site. Allow users to add emailaddress objects to the container that you've set up for notifications. The "new object" hook will get the emailaddress objects from the container, and contact the email output module to send out the notification.

It sounds simple. It is simple.

Certainly, there are some things that Inklog just won't do well… or, at least not easily. But I can't think of any.

There are some limitations to Inklog. First of all, if you want to customize the way your site looks, you need to know HTML. You can use Frontpage, or Homesite, or whatever to give you a hand but, in the end, you'll have to edit some HTML to get it to do exactly what you want. Now, Inklog will support themes. So, if someone's already built a theme that looks the way you want it to, you can simply install that. Additionally, themes can have configuration values. So, in the end, I guess it's possible that if someone wrote a flexible enough theme, you could get away with not knowing HTML and still get it to look the way you wanted. But, that would be difficult to do. Secondly, if you want Inklog to handle a new object type, you have to be able to code. Currently, you have to be able to code in PHP. In the future, it's possible that any programming language that can use XML-RPC (or maybe SOAP, or some other standard remote object calling method) can be used to code modules. But, at this point, it's PHP only. Finally, if you REALLY want to make your site to do amazing or unusual things, you have to be willing to, not only edit HTML code, but possibly insert some "code-like" constructs into your HTML. They aren't any more complicated than Movable Type's template format. but, you will need to have a general understanding of very basic and simple programming concepts (what a variable is, what a function call is, what an if statement does, what a foreach loop does, etc). But really, if you can code HTML and cut and paste JavaScript, you can handle it.

That's it.

I hope this makes sense and helps some of you understand what it is I'm working towards here.

If you'd like to help and know PHP fairly well, please let me know. I'd love a partner in all of this. Additionally, if you have comments or questions about Inklog, feel free to leave them here.