27 Feb 2015, 02:27
Last time I looked at phpBB (must be eight years ago now!), "mods" were so far beyond a joke it wasn't funny. The instructions were literally "insert this line between these two lines, this line between these two lines …"
True plugins carry a lot more overhead, and the enthusiast-level Web has always tended to follow the pattern of interpreting/compiling on demand, using fresh database connections every time instead of connection pooling, instead of running applications as daemons with threading/forking, so there's a huge need to reduce the compilation and initialisation cost of scripts. (Enterprise-grade systems of course run daemonised, but even MacASP would cache compiled scripts.)
All I don't get is why you have to host an image only to have it re-hosted — unless you're using URL fopen() (which isn't sensible), it's more work than just reading files from CGI, as I recall. (I still work with PHP sometimes, but mostly it's Perl and a custom framework.)
I can certainly dig out my fast resample.
I'm still torn between the idea of having a keyboard and switch database website (regardless of the fact that it would go stale) vs the wiki, since the two would end up out of sync and wouldn't tie in with each other.
I'm looking at it from two angles. It shouldn't take very long to build a switch and keyboard database site, focusing just on the functionality and not the looks. As such, it would be a totally ad-hoc system.
I've had an idea floating around my head for many years, for an object-orientated content management system. From the user's perspective, you'd do something like this (very simplified, as our data model is fairly complex):
Define class "Manufacturer" as having: name, description
Define class "Image" as having: image (image), summary, description
Define class "Switch" as having: manufacturer (Manufacturer), model, is_clicky, is_tactile, description, images (list:Image)
Define class "Keyboard" as having manufacturer (Manufacturer), model, part number, switch (Switch), description, images (list:Image)
The system would automatically provide object creation pages where you'd add entries. For each class you'd have views: essentially named templates that you'd call as methods. The default view would present a full page. You could list items by iterators, which themselves call either a default view, or a named view. For example, the default view for Keyboard might include:
<h2>Gallery</h2>
[iterate :images (thumbnail)]
"thumbnail" would be a view on class Image that shows the image property as a thumbnail with the summary below. (Granted, you'd need an extra level of abstraction to apply different summaries when re-using images across pages.)
There'd also be a need to have an enclosing template to wrap the gallery, which could even include the <h2> if you wanted the iterator to be dropped if the images list was empty. There would be an option to use views to present custom objection creation forms.
The down side is that you need an interesting object-relational mapper to build this with, presumably, dynamic table creation, but it would be a rather nifty site builder. I figured at the time that it would even cover building whole forums.
Whether something like this already exists, I don't know. The big down side to replacing the whole wiki with it, is that you'd lose the revision history and advanced MediaWiki templating and markup, as well as the freedom to lay out pages as flexibly as you can now, but at the same time, you'd be able to rationalise categorisation, infoboxes etc into a uniform system that's easy to edit and easy to query.
As I see it, the likely situation is one of:
a) No such software exists because nobody wants it (I've well used to writing programs that nobody wants)
b) Such software exists, but it never caught on as nobody wants it (the idea goes back to Allaire Spectra, that I think worked along these same lines, but was insanely complicated)
The advantage of such a CMS would be that it could be made use of by people outside Deskthority, but it would require far more work than simply building a quick ad hoc site.
That's enough mad ranting for one night.
