This type of thing is almost always a bad idea, but I'm thinking about it anyway: I'm giving some serious consideration to a complete rewrite of WebCit. As some of you have observed, I've taken quite a break from Citadel because of job and family commitments, and over the last couple of weeks I've started getting back into it again. As I move the various "external files" -- things like user profiles, user photos, and of course all of the system state and configuration -- into the database, here's what I'm finding: * Citadel Server continues to be a nice solid design. There are a few things I would change but not much. * Implementing the corresponding client changes in WebCit has been a disgusting mess. WebCit came into existence 20 years ago -- yes, TWENTY years ago -- when I barely understood how web applications worked, and basically just hacked together something that would speak to a browser and maintain a session with the Citadel Server. Even the update that made it a standalone web server is about 16 years old. Here are the things I don't like about it: * It is spaghetti code of the worst kind. Finding the execution path of a single transaction takes you back and forth between half a dozen files.
* Too much state is maintained. (And it's showing -- I've been seeing a lot of "not found" screens lately) * The template engine, although much better than hard coded HTML in the source files, is difficult to maintain. * WebCit on mobile basically doesn't work. * There is tons of CSS and JS that isn't even used anymore. Very much cruft. * A lot of what's in there is designed to work around bugs in browsers that have been obsolete for years. * Adding support for CALDAV and CARDDAV will require *even more* spaghetti. So what am I proposing? Basically, a web service that resembles something built in the 21st century: * Streamline the HTTP[S] server code into a single source module that handles nothing but the web protocol, designed from the start to handle things like HTTP uploads and other special considerations. Full support of inbound and outbound content-types throughout the system, every transaction, every time. * Strict REST API. Force all paths to begin with a prefix like "/ctdl" so that site operators who want to mix WebCit with another web server can do so. All media will be REST enabled so that you can request, for example, http://uncensored.citadel.org/ctdl/r/Citadel%20Support/123456 and it would spew the correct data at you, regardless of whether it was requested by a DAV client or as part of a browser rendering. * Let the majority of the UI work be handled by an existing CSS/JS framework. I'm considering Bootstrap [http://getbootstrap.com] because it seems to be very popular, good looking, and mobile-friendly. For sure, we get rid of Prototype and Scriptaculous. If we need more scripting than Boostrap by itself can support, we can add in JQuery or something equally as modern. There is a lot that we'd keep from the existing system, but we'd move over the usable parts one bit at a time. For example, all of the work that has been put into translations has to be kept; we can't ask everyone to start over there. And the basic web server engine *works* but it has to be brought over and streamlined. But here's the thing: this will cause the progress of development to appear stalled for quite some time. This kind of thing has famously sunk projects before. But I'm starting to think that WebCit has become so unmaintainable that it's necessary. What do you all think? To be sure, I want to finish the cleanup of Citadel Server's directory hierarchy first. I'm really happy with the progress on this, and it feels great to have all of those external files disappear. A lot of it felt like relics of a monolithic dialup BBS disappearing and getting replaced by modern technology.
