I have been made aware that it still isn't very clear WHAT Inklog is. So, I'd like to submit a better explanation.
Inklog is really two things.
1) It is a framework for developers to use to create applications in a
simple efficient manner that removes the trouble of dealing with
template engines, configuration, data storage, and other annoyances. It
is a framework that, uses the relationships of various objects to infer
meaning and, therefore functionality.
2) It is a collection of applications created in this framework all running together.
When I started writing Inklog, my goal was to get #2. However, in the end, I realized that required me to write #1.
If you're a developer, you care about #1. If you're an end user, you care about #2.
At this point in the game, I'm still working on #1 while keeping in mind the goal of #2.
Inklog is similar to any of the millions of application frameworks that are out there today. It's difference lies in the fact that it intends to allow simple integration of remote and unrelated components by non-programmer end-users. It takes an object oriented approach (in both code, and in the way data
is stored and represented) to accomplish a tight integration of
components. Inklog's goal is to force component authors to write in
such a way that their methods, objects, and functionality are reusable
throughout all the other applications with very little knowledge
required.
In a nutshell, the goal is to make it very easy for people who are only
slightly experienced with all things technical to use components
created by seasoned programmers in a manner which is consistant with
the look and feel of their current site.
Let me give you an example. Let's say I want to track the weather in my
area. So I use Inklog and create an entire system to store historical
weather data for my area and allow me to retrieve it and sort it and
graph it a million different ways. Once this module is built and
available to the public, it opens up a whole new realm of data for
every Inklog user. Let's say that I just want to display the current
weather on the front page of my blog. That's no problem, because of the
way Inklog forces programmers to write, I can simply install one or two
pieces of the entire weather system and have a functioning weather box
on my front page. Additionally, because of the integrated theming and
templating, when I install that weather box on my front page, I am able
to make it look exactly as I desire it to without editing a single line
of PHP.
Take, for example, the blogging and image gallery world. There are great
blogging scripts out there (movable type, bblog, wordpress, etc).. and
there is at least one really good image gallery script (gallery).
However, the two don't interact at all. First of all, they don't look
even remotely the same and, trying to get gallery to look like anything
other than a colorized version of gallery is close to impossible
without really digging in to the code. Secondly, trying to get my most
recent gallery image into a box in the corner of the top of my weblog
page requires a good amount of PHP coding and internal knowledge of
both the blogging software and the gallery software. Inklog aims to
defeat that requirement.
It does so by making each element of a system nothing more than an
object. The way it is designed almost forces a user to program this
way. To use Inklog and NOT program this way would actually require MORE
work than not using Inklog at all. And, because everything is instantly
templatable and configurable and authenticated, the site owner using
these components is capable of making things work exactly as she would
like, without needing to code even one line of PHP code.
The Inklog framework will excel at enabling applications that primarily
store and present data (like a weblog, an image gallery, a discussion
forum, a software repository, a file trading site, a bug tracking
program, a shopping cart, etc) as opposed to applications that
primarily compute or convert data (like… seti, image editing
applications, RSS readers, etc). It isn't that Inklog can't do those
other things… it just doesn't really make them A LOT easier… unless
of course it is desired that the output be themable/templatable, in
which case, that alone is enough incentive to use Inklog.
Because of the design of Inklog everything inside of it is an object that can be accessed and displayed in any fashion from within any other object. Let me give you an example.
Let's create an image gallery application. First we make a "gallery" object. It has properties like "description". It contains things like "album objects". It has actions or methods like "view" or "create album". Next we make an "album" object. It has properties like "description". It contains things like "image objects". It has actions of methods like "view" or "create image". Next we make an image object. It had properties like "description", "image data", "width", "height", "format", "location", "subject", etc. It doesn't contain any objects at all. It has methods like "view". These three data types and their associated methods and templates work together to provide you with a method of creating an image gallery. When "viewed" the gallery object displays a list of its albums. When "viewed" an album object displays a list of its images. When "viewed" an image object displays an image to the user.
Now let's create a weblogging application. First we make an "article" object. It has properties like "author", "exceprt" and "content" and methods like "view". That's all this takes. When viewed, the "article" object displays the content as defined in the site templates.
Now let's create a comment box application. First we make a "comment box" object that merely holds comments. It would have properties like "active". It would have actions like "view" and "add comment". It would hold "comment objects". Next we create a "comment" object. It would have properties like "author" and "text" and "title". It can hold other comment objects (for replies). It would have properties like "view" and "get replies" and "add comment". Done.
So far so good… now here's the fun. If I create a "comment box" object inside of my "image" object from the gallery application, what happens? That's right… now people can comment on the image. It's that simple. Even though the original author of the "gallery" applicaiton didn't intend to enable comments, an average user is able to take two unrelated components and connect them all using the same look and feel.
It gets even more interesting. Say someone else creates a "shopping cart" application. The shopping cart application can be written in such a way that it doesn't have to know anything about what it's selling and it can sell any type of existing object. What it does do it add properties to that object with the information it needs. So, say I want to sell my photographs that are in my gallery. Through the "shopping cart" application, I would make a particular gallery item "sellable". I would supply a "price" and perhaps a "shipping/handling charge". Now the item is sellable and can be held in a cart. Additionally, if I so desire, my image gallery can now access that price and inform the users browsing the gallery that a particular image is for sale at a certain price.
Everything works together because everything is stored in the same way. Because of this shared data model, all components can ensure that they know how to access other elements in the system. Additionally, they know how to render them and how to annotate them. And all of this is done in a templatable themable fashion.
