Naga - a fake FAQ
Thu, 05 Feb 2015 08:35:51 -0000
A small collection of answers to questions to my content management system 'naga' that could become member of a FAQ.
Update: Converted the FAQ to the new markup and added a section explaining why bother with dedicated markup languages in the first place.
Update: Corrected some typo...
Update: Corrected some typo.
Update: Added some info about the why and what to do with that page

Why another Content Management System

There are a heck lot of CMSes floating around, why bothering writing yet another one? Besides the effort one has to invest, each line of code written produces bugs. Established projects seem to have found a way to minimize the bugs they contain, or at least managed to avoid or hide obvious coding and design mistakes. They would not have established themselves otherwise, would they?
On the other hand, most of them require a lot of infrastructure to support them, for example some SQL data base. Most of them try to be as flexible as possible, which is a valuable thing to pursuit. However, it also makes setting it up rather difficult - in other words, some of the time you saved by not coding the CMS on your own you will have to invest to get into an established CMS. And ultimately, in my case, I wanted to learn. I have experience in writing C, C++, Java, Perl etc., but so far, I did not write a program in Python longer than a few lines of code. I know writing software in the 'traditional' way for single core CPUs, networking and system programming, etc. I know hardly anything about recent development regarding web applications, where 'recent' means 'of the last 10 years or so'. Yes, I started Naga as a CGI server-side scripted page, but progress is planned ;) . My intention, to be honest, is actually not to come up with a decent product, but to walk the path towards it.

Why 'naga'

You could resolve it to something, one suggestion could be 'news access gateway'. The awful truth is, that currently, the scripts on the server-side is python, which denotes a kind of snake as well as a language. On the other hand, I am currently going through some kind of 'Indian weeks', and I have learned naga is some Sanskrit word meaning snake as well. Not the best of all stories, but there just is not more to say about that...

Why HTTPS only

The first and by far most important reason is: Just do not use unencrypted connections. HTTPS may be flawed in one or the other way, but it still provides some kind of safety bare HTTP cannot provide. I know, the certificate system is doubtable, the chain of trust cannot be trusted and, and, and. However, even if one does not trust that chain, you still have the advantage of once the connection has been established, noone can eavesdrop on the traffic. Naga for example, transmits passwords unencrypted. This is done due to the fact, that passwords do not only have to be transmitted but also saved onto the server. If you think about it for a little, you will end up that the straight forward solution for storing hashes instead of the passwords collides with the straight forward approach of transmitting hashes instead of passwords. Think about it, and if you encounter the problem AND come up with a proper solution, let me know :) My solution has been storing hashes, but transmitting passphrases plainly. This is a really bad idea if you do not use some encrypted channel, obviously.

Why burdening with a markup language and not just sticking to HTML?

There are two good reasons to implement an own markup language. Firstly, Just letting users enter anything they want poses a serious security threat. Here, only authenticated users are able to send content to the server, so this is not that big of a problem in the case of naga. Secondly, if one uses plain HTML, the content becomes really tightly location dependend. Especially the second point deserves some explanation: If you want to link to an article on your own page using plain HTML, you more or less have to enter a fully qualifying path to it, e.g. . If using a dedicated markup language, one can just design it in a way that the editor needs just enter a 'key' identifying the article and ending up with some markup like [c newnagaversionreleased] . Neat, isn't it? And if you ever happen to have to switch your domain, or the location of the data on your server, you do not have to adapt every single link within your articles any more...

This page looks awfully bad - arent you ashamed at all?

No. The intention of this page is not design, but playing around and figuring out about stuff. I coloured each other line in a table blue, not because it looks decent but because I wanted to try whether it works.

The code is mean, ugly and bug-prone - do you really intend others to use it?

No. Just look at the preceding answer...

What you wrote about subject XY is crab - why dont you just post about stuff you know about?

Again, its my intention to get to know about stuff. This page is there for testing stuff and checking how things or wether ideas work. What I write is just a snapshnot of my current knowledge or opinion and likely to change. I write it just because writing stuff down lets me understand the things more thoroughly. Moreover, presenting how I reached a conclusion enables others to evaluate it and figure out errors in my thoughts eventually preventing them from being lured into the same wrong diection. Or so.