The first step should always be to take a step backwards. In this case, a step backwards to consider what has happened for this project so far.
TyNET started out as a webcomic site. Back then I never had any plans to build this into the multi-service multi-server network it is today. The motivation to make it was that I wanted a Content Management System that had seamless integration of a webcomic homepage and a forum. The reasoning for this was simply that most webcomics sites had two completely separate climates, one for the comments section and one for a forum. Users needed to use different logins or even create multiple accounts to use both and they never had the same people visiting either. I wanted to avoid this split and this annoyance of having to create multiple accounts.
Before I started building my own crappy implementation of a CMS, I took a look around at the alternatives. I knew ComicPress was a popular choice for publishing comics, but I couldn't find a good forum software plugin for wordpress at the time (there might be one now, I don't know). Other CMSs either didn't have a good comic publishing tool or a good forum (some even neither). Since I had, and still have to a point, a pretty short fuse for annoying and inconclusive research, I decided to give it a shot believing it would be no sweat since I was just that good of a programmer. So, with no experience in webdesign, PHP programming or anything I set out to make something that fitted my needs.
TyNETv1 was a fairly horrible website with awful layout and style, ludicrously bad PHP code and was generally a monstrosity to both code and use. I don't have any piece of sourcecode left of it now and I think there's no loss in this fact whatsoever. As I noticed that my first approach was a clusterfuck and nowhere near as extensible as I wanted it to be, I set out to rewrite it from scratch.
Enter TyNETv2: “shine”. Released on 2010.07.14 and totalling around 7k lines of code, it was quite large. I even started dabbling into a bit of modularity and began using classes. It was still really horrible in terms of performance (almost a complete database load on every page call) and structure (no architecture whatsoever). There were a bunch of different parts for it, like a wiki (which I don't remember), rss feeds, gallery, polls, download center, etc. After blazing through two versions in a year I decided it was time to start over again and do it right this time.
And on the 2011.09.17 it was mostly done. TyNETv3 “glow” got released with a final score of around 12k lines, almost twice as big as the previous version. Actually, I don't know how many lines it was upon release as I kept adding quite a bunch after release still. So I'd guess the base was around 8-10k. This time I wanted to focus on getting it to be modular. I wanted to be able to have something that lasts and I could extend without further ado. Not to mention that I got quite a bit concerned with the speed implications, so focusing on a system that would reduce extraneous load was a good idea. This version also introduced the system still present in v4's Core, which is the way it loads and handles page calls and how it redirects them to the proper module. The code quality was infinitely better compared to my first attempts, but it still lacked in some areas. Most glaringly of all, it was not designed. The system was a loose thought game that occurred to me one day and I then decided to implement. I never had any major design phases, so it was obvious that this system too, was far from perfect. Of course, it had to be that I got bored and fed up with programming things people could actually use. TyNETv4's development started sometime around January 2012. Unlike the previous versions, which were complete rewrites in every component, this was supposed to be a rewrite of the core system and a partial migration of all the modules. I ended up having to rewrite a lot more than I originally wanted to either way. Also different was that I actually did some planning and designing around the core and what it was supposed to accomplish. Since v3, comic and forums weren't the focus anymore, it had rather shifted to the more general idea of building a web framework that basically just handled some simple things for you and then left almost all the rest up to the writer of the module and the administrator of the website. I'm still quite happy with the system I came up with for v4's core and believe the structure is a sound idea. The individual modules are often heavily lacking in features and quite bug-ridden though, so that's not so fantastic. Still, this was a system designed to stay, as I didn't think I could bear another complete rewrite, especially now that the it actually worked smoothly and allowed for anything I ever anticipated I could want.
I often thought about actually publishing the sourcecode for TyNET, but I never did because it always was and still is way too rough around the edges for my liking. Putting out a shoddy and incomplete project would feel very wrong to me. Maybe some day I'll release it, but not for now, no. On the 2012.08.05 v4 got rolled out and replaced v3. Since then there's been a couple of additions and changes, but development has pretty much been halted for well over half a year now. There's still some direly needed modules half-done in the repository and countless bugs and improvement notes. V4 is now totalling around 28k lines.
The problem is that I lost interest. I've tried very hard to continue developing and creating these modules I so direly need, but I lack the energy to. There's more intriguing and fascinating things out there that I want to try and web development very often feels very much the same, especially when you've done as much as I have and so much of it was almost to the point the same. Even now I still adore and take immense pleasure in creating a scratch layout for a new module and adding all the user interface stuff that would be so sweet to have. But it's only a fraction of the work necessary to actually make the module. One also needs to plan out the data structure and database, write the form handling, handle all the site interactions and smart data loading and so on. There's a lot of code and logic going into getting the right data and filling in the gaps in the right template. So much of this is almost precisely the same as I've done a hundred times for the previous modules and versions, but still distinct enough not to be well automatable.
Yes, there's tools to click together designs and code for it, but I resent them because they create garbage code and I don't want to have to look at that or debug that, not to mention that there's definitely no such tool out there that would work seamlessly with TyNET. Yes, I'm to blame myself because I decided to build everything instead of using all the much better existing frameworks and CMSs. Yes, I have the feeling that I don't need to do any of this as I can't see anyone really caring about it. V4 works well enough, I only have very few visitors anyway and I don't have enough friends who'd be interested in discussing or sharing my enthusiasm for this field. Outside pressure is something I'm very often lacking and is also a large factor in why I'm constantly jumping projects instead of finishing them. But this blog isn't about that.
So let's get back to what TyNET as a framework is and what it should be able to do as of v4: ul{l_Provide a modular, class-module based framework_ l_Allow website administrators to decide which addresses point to which modules_ l_Allow website administrators to configure modules to a large extent_ l_Provide a set of core functions and tools to ease integration and site building_ l_Handle authentication and user management_ l_Abstract away most of the DB interaction with a simple data model class_ l_Automatically parse the URL parameter and give modules an easy way to use that info_ l_Provide a triggering system that allows modules to bind and extend each other as the webadmin sees fit_ l_Provide a simple theming system to allow easy integration of different styles_ l_Provide a uniform administration interface to configure modules_} That may seem like a lot or very little, depending on your perspective. What v4 is still lacking seriously for me is a good templating system (separation of html and code), better integration of modules and automatic form handling. These are mainly points that increase productivity for programmers and increase maintainability.
A v5 would have to be designed with these lacking features in mind. I intend on continuing v4's core module design though, as I still find it very appealing. On the more technical side, I really want to get out of using PHP. While it was very nice to use for the DB integration (as it allowed me to make a really slick class to map fields), it's really quite awful in many other areas and there isn't a singly day in PHP coding that I don't have to hit up the manual repeatedly to make sure I'm using function x right. Moving away from PHP would, however, also mean rewriting everything again. Ho boy.
Still, I am determined to do this. I won't be rewriting everything from scratch. V4 and v5 will be existing in parallel for quite some time until I some day maybe will have finally rewritten everything for the new system.
Next up: A glance ahead and of the horrors to come. It's time to conduct some research.
Written by shinmera