Avatar

Building TyNETv5 Pt. 15 - Conclusion

2013.09.14 11:12:19
Index

image This Monday university starts for me, which means I have to stop working on this for a while, at least until I figure out how to deal with everything. So I'll take yet another step back and see what I've accomplished and what I need to focus on next.

An easy way to talk about applications is to talk in abstraction layers. Or at least I find that a suitable way to track progress. So, what has Radiance managed to abstract away so far? Let's take a look.

Webserver Radiance acts as a layer above the webserver, the currently included one being Hunchentoot. However, it is supposed to wrap over all accessor functions, as to hide the webserver details in the library completely. This is to allow the possibility to switch to another, possibly more convenient or faster server at some point in the future if so needed. It also allows me to provide a uniform API for all things webserver.

Encapsulation Modules provide a unified way of encapsulating webapps. This is an important aspect in what Radiance tries to achieve. TyNET has always been about providing multiple websites or systems in one place, sharing functionality. This grew out of the need of combining blog comments and forum, but then expanded into a more general concept.

Data Exchange As a direct consequence of having modules that need to make use of each other, there needs to be a way of standardising this data exchange. TyNET (since v3) has had a way of doing that loosely through hooks and triggers. But now for the first time, it also provides an actual mechanism to construct interfaces that modules can rely on to exchange data to arbitrary implementations, making the whole system very flexible.

Data Storage Any dynamic site needs a way to store and retrieve data. Radiance makes use of the interface facilities to provide database access through modules as well. This means that it is (in theory) possible to easily write a new db-access implementation for whatever you like. Out of the box, Radiance currently supports SQLite and MongoDB. Although I will probably extend it for PostgreSQL and MySQL at some point in the future.

Page Construction Since this is a web-framework, one central aspect of course is how to build, change, display and handle pages. Radiance covers this in a multitude of ways and, in the spirit of TyNET, tries to force as little on the end-user as possible while still assisting wherever needed. A sub-project of this is lQuery which provides a library to easily modify and construct HTML documents.

API Support The ability to easily provide public APIs is very useful to have nowadays, as third-party extensions and enhancements have become commonplace. TyNETv5 has a simple mechanism to provide REST-API pages that automatically transform and validate data, making it easy to make a site extensible.

Authorisation Sessions, accounts and authorisation are also key components in modern frameworks. Radiance provides a nice interface here as well and even includes a standard implementation that allows for extension of authentication mechanisms. By default OAuth, OpenID and password storage are supported. Aside from this Radiance also includes a unified way of checking for account permissions and managing sessions.

Administration On a more high-level note, TyNETv5 provides a couple of simple functions to easily construct administration panels for modules, which then appear in one unified place. Administration front-ends are a requirement for CMSs, especially multi-layered ones like this.

Introspection Despite the rather strict encapsulation present in Radiance, it tries to offer a few ways to gain insight into the workings of other modules, without having to specifically write code geared towards them. This aspect isn't as worked-out as I'd like it to be, but it doesn't have a very high priority either, so I'm not worried.

Hey, that is a quite couple of things actually! All parts still require a lot of work and polish, but I've come a ways. Sadly I did not get as far as I would've liked. I've become sidetracked far too often and even had to backtrack a couple of times to clean up my mistakes. Even now there's a few places that I'd like to rewrite completely to get rid of all the crud that is still present due to my incompetence, ignorance and lack of experience.

Choosing this as my first real project for Common Lisp was both a good and bad idea. Good in the sense that it gave a lot to work with. In fact, it gave me so much to work with that I don't know if it'll ever end. However, it is also bad because I ruined a lot of core features and functions with my inexperience. Now that I'm already a huge lot more comfortable with Lisp and know a lot more about how to write properly with it, I feel a lot more competent and I'm sure I could do a much better job at it. There's still a bunch I need to learn about Lisp and its ways, but so far it has been an immense joy. I have not had a single language that intrigued and allured me as much as this. It is hard to believe all these quotes of Lisp users being snarky about other languages and so on, but even though I don't want to sound like a douche I am inclined to agree with them. Common Lisp is the single greatest language I have ever worked with.

However, as university starts and because I know myself too well I cannot risk falling into the same trap again. I love working on my own ideas and projects more than anything, but I cannot let this ruin my education. I need to figure out how to balance my life properly first, before I can indulge myself in this again. That is why I have to stop, at least for now. But, I will talk about that in more detail in the next blog entry.

For the future of TyNET, there's a bit of polishing I have to do as indicated previously. After/during that I also need to build a few toolkit-like functions and fix a few places up. Once that is done I can finally, finally move on to the project I've been meaning to do for over a year now: A project hub. A place to keep track of everything I do, to submit bugs to it and generally organise teams and contributions. When that has reached a workable state I can get to the project I've announced a few times before, which is the Kanji site. Once that is done, I will get to re-implementing TyNETv4 modules in Radiance and start a gradual and partial migration. I wish to, at some point, have moved away from v4 and PHP completely. Let's hope the way to it will prove to be interesting, but not all too painful.

I will write about this again when I've resumed my work. Until then, I hope I have awoken at least some interest in people with this project. I would be more than happy to explain the details and inner workings in greater detail and nothing gives me more joy than to hear that people actually care about what I do. If you think you'd like to work with me on this or if you are simply intrigued by what it is, do let me know and I will see to it that I can fulfil your request.

Written by shinmera