I never went to an actual coding class. I never had a professor teach me anything related to programming. All I know has been out of books, tutorials, specs and discovery. There are a bunch of problems with this approach, most of all that I started out with writing pretty damn bad code, had no idea of how to structure or plan anything and so on. These are all things a good professor could avoid. Regardless, I think this approach also has the benefit of dynamic learning and backstory. That is to say, I can follow back my timeline and see where I've improved and I know why my current style is better than before. I don't just do things because someone told me to.
If there's one thing that I've discarded for a long time, it's pre-planning and documentation. I've since realized the usefulness of this and come to love taking the time to think things through beforehand. Still, there's always something that I've been missing, which is a philosophy or principle to follow. I never deemed it necessary and just went to code and do what I wanted. One may argue that that is in itself a principle too, but I say the absence of all principles cannot be a principle in itself. Whatever the case, I thought it's time to fix this issue and come up with a primary philosophy to follow for TyNETv5.
That hasn't been as easy as I expected it to be. I don't want to constrain myself to a radical philosophy, because I know all too well that circumstances vary and change. So after a bit of thinking around and reflecting on what I've done I have come up with something akin to a principle. I'm fairly sure it has an actually recognized name, but I'll call it “Interface First Design”. What this insuates is basically the approach of designing the UI first and then coding what's necessary. I chose this as it's been the most common thread throughout TyNET.
I think this is a good approach, as it avoids unnecessary extensions that are never used anyway. Of course, this principle isn't just limited to UI, but can also be applied to Software/Application interfaces. It's also reflected in Test Driven Development, as a “use case” is defined first and the functionality is modelled after that. The only problem with this approach that I can predict is that it might be difficult to extend such a framework or module later, since it isn't necessarily structured with flexibility in mind. This risk is a minor one though, as refactoring is always a good thing.
With a simple philosophy settled down, it's time to plan a bit ahead and see what this framework should be capable of. I've always been of the opinion that frameworks should have a core that is as light as possible and then implement the rest of the required functionality through itself. Sort of like a language has a core syntax, but implements most of it's SAPI (which might just as well be part of the language too) with itself.
v4's core is made up of three components: the dispatcher, the module loader and the database. I'll illustrate this from the perspective of a user requesting a webpage. This results in a call to Apache, which redirects it to the PHP interpreter. Thanks to mod_rewrite, almost all calls are redirected to deparse.php, which is the dispatcher. It calls config.php, which initialises the database connection and loads all necessary constants. The dispatcher then analyses the URL and figures out what it's made up of. Next it calls the module loader on a special trigger: “HITsubdomain” (subdomain being the subdomain that was requested by the user). The module loader then checks if a module registered a hook on this trigger. If so, that module and its dependencies are loaded and a special function in the module is called. The module does its thing and finally the database connection is closed and the page is done.
If you know a bit about webprogramming and especially efficiency, this probably sounds quite expensive. I'm basically loading a database table before I can even get to building the page and I'm also doing a lot of dependency loading and probably a bunch of modules might be initialised that aren't even needed to build the page. This all is actually still a lot more efficient than any other previous version and I don't think there's much point in sacrificing more ease in exchange for that bit of speed boost. The reason why I'm loading the module delegation out of the database is because I wanted the webmaster to have full control over which module gets what subdomain or directory and how they're all organised.
This process most likely won't change at all in its principle. It will become “Lispier” to account for the different programming style. It'll also become more interface driven as the module class will have actual interface requirements imposed upon it to make inter-module hooks easier (extending one module's functionality through another). The new HTML rendering method in v5 will make extending functionality through modules a lot easier than before too, which I'm really excited about.
I'll talk about the new module class in the next blog, but there'll be a lot more restrictions on that to increase the metadata amount and let the framework take a bunch of repetitive work off your hands. Another thing I'm intending on introducing (but haven't quite figured out how to do it technically) is “fragments”, which is basically code-based caching. This technique is already implemented in TyNETv4's Purplish (chan) and basically compiles the page not directly to HTML, but to a minimal code form that still allows for dynamic pages. This generated minimal code is then saved to caching pages and will be called directly on a page call. Once an update happens, the cache pages are compiled anew. This makes it possible to have dynamic pages while possibly reducing the computation cost greatly (as well as minimizing database calls). Creating a generalized system for that in Lisp will be a new challenge though and I have yet to do some tests and research to find out how to do it well.
So that's about it for the general plan with v5's core. Next up: Taking a look at the reformed module system.
Written by shinmera