I had a long talk with Matt yesterday that led me to almost 6:00pm without even realizing it. I haven't had that much nerd contact in quite a while and it was much appreciated.
First off, he helped me get a working Java environment on my development box complete with Tomcat allowing me to author Servlets and JSP. Then we dove deeper into application development and how the idioms used by individual programmers for different things can become a barrier to communication and the expression of ideas because, in many ways, it's almost as if those two people are speaking different languages.
Finally, he geeked with me a bit about Inklog. I am continually getting stuck on the smallest most insignificant portions of the framework. He helped me to understand that the "GUI" of it all — the way it "looks" to the end user — isn't nearly as important as how it works inside. The GUI can be changed, rewritten, or adapted to suit the needs of other users. However, the internal workings are the parts that no one is going to want to touch, if they can help it.
When it got right down to it, I realized that I was trying to accomplish the impossible by making the system so flexible that anyone, despite their competency level, would be capable of making it do anything. Unfortunately, this wasn't working out very well. In the end, I realized I was trying to cater to 0.0001% of the population instead of focusing on what it actually does and the features it represents.
Hopefully, that's out of my system now. I have a few more hangups with how the code should progress, but at least I'm on a clearer track now. My biggest concern now is that so many pieces are so different from one another, that I don't know how to make them act the same. For instance, I'd like to allow each object in the system to be displated in an infinite number of ways. Let's say I had a text object that I want to have displayed as HTML. That's easy: the text module converts it to HTML and spits it out. But then let's say I want to display that same text object as RSS. Now I have to edit the text module to handle RSS. I'd rather be able to drop in a plugin or module that knows what RSS is and have it do the work for every module. This is VERY simple when you're dealing with output that can represented as some for of text, but imagine, for a second trying to deal with a JPEG image, or some MP3 audio. At this point, the RSS module would have to know how to convert that into something useful. And it would have to be competent enough to handle any new input types that might come along.
It's all very complicated and I don't really know how to express myself. Maybe I need a flow chart or something. Let me try again.
I have a module that handles text objects. Basically, it knows how to read plain text and nothing more. If I create a module that knows how to output RSS, that RSS module is going to require that its input be in a format it understands. That's where the trouble comes in. Either I need to use some universal internal format for representing ANYTHING (which is impossible at this point, since it doesn't exist and I'm certainly not the guy to write it) or each input module must also handle output and users will be limited to output types that it understands. Even if I accept the fact that, when someone wants to output RSS the items that they wish to output in that format must be updated to handle RSS, there are other problems.
Consider that a user might want to have four different HTML renderings of the same document. One for regular browsers when being viewed on the website, one for limited browsers when being viewed on the website, one for embedding in other HTML documents, and one that is printer friendly. Well, the output, in each case, is HTML. So, even though the text object module knows how to render HTML, how will it know which KIND of HTML to generate? At first, I was thinking that, each module could simply trap a few different output types that it handles specially. If the requested output type isn't one of those, it'll assume the output is some text format and try to find a text template (powered by Smarty) that can handle such output. In the event that such a template cannot be located, it would notify the user of its failure. But this doesn't really seem like the best way to do it simply because, things like RSS always look the same. And, in most cases, they can rely on the text module or the HTML module (depending on user preference) to handle the object rendering, they are merely wrapping it something that looks like RSS.
So I'm not really sure how to handle it all. My goal, in the end, is to make adding, say, an ATOM feed, trivial. I don't want to have to touch every module that outputs RSS and give it the additional ability to output ATOM. That's a lot of work and may involve altering modules that other people have written, modules I don't even know about. Instead, I'd like some way of just dropping in an ATOM module that instantly makes everything know how to do it.
Here's what I have now:
Agent/Dispatcher (This chunk of code knows how to speak whatever protocol you are trying to interface Inklog with. This would be your index.php, your index.jsp, or the thing you run out of your .procmailrc. It would determine what is being requested. In this end, this chunk of code also sends the formatted output to its final destination)
Auth (This chunk of code ensures that the requestor has the permission to do whatever he/she is asking to do. It interfaces with Datastore simply because, the permissions information is stored alongside the content and the datastore is the way to access all of that)
Datastore (This chunk of code connects to the database, retrieves the requested object, and invokes the module that is designed to handle that type of object)
Module (This chunk of code knows the input type of the object that is being requested. It specifically knows how to read that type of file and is capable of outputting it in several different formats. In the event of a text based format, it uses Smarty to empower more users to be capable of altering the style of output.)
They all link up like this ("->" signifys a call to that chunk of code, and "<-" signifies the return of data. The words in parentesis signify WHAT is being done or returned. Items in square brackets represent what is being passed to that chunk of code):
Agent (initial request) -- (Parse Request to determine what is being asked for) -> Datastore [item location] (determine if object exists) <- (availabilty of data) -> Auth [username, item id] (verify permission) -> Datastore [username] (looks up permission data) <- (permission data) <- (presence of proper permission) -> Datastore [item id, requested format, extra parameters] (determine module to handle requested object type) -> Module [actual item data, requested format, extra parameters] (handles requested object type) <- (returns formatted data) <- (returns module output)<- (outputs data to requesting client)
Hopefully, that's easy enough to read and understand how things work now. Maybe someone can come up with a way to handle what I want to do with this knowledge.
