let me see you stripped down to the chitin.
or: a rough sketch of steps i'd like too see taken concerning antville (the software).
first of all, apologies to all the folks who tried so desperately to contact me as one of the antville developers. (i am still reading my mail, btw.) it's been some bumpy times lately and hardly a free minute for practical antwork, however i've had a few headaches from being lost in thoughts about how to react or continue...
it's so difficult for various reasons:
- the development team is practically non-existent, anymore.
- the current antville design still resists flexibility and modularization.
- there's a lack of supportive backflow from other antville developers (instead we have a strange competition of the same product with two different names).
- helma, which antville is built upon, is shifting towards a completely rewritten version 2.
e.g. to implement a new action i do not only need to know a little bit too much about antville's internal access permission management i even have to write every permission check (i.e. whether a user is allowed to create, update or delete an item) mostly from scratch.
and even displaying a simple feedback message is quite a pain in the neck due to an internationalisation engine that was half-heartedly implemented and never finished.
from my own experience creating antville's parss client i just would not want to do such a thing again at this point.
well, obviously i am scared of my and our own code. and pretty hesitating to touch it for the benefit of a new cool feature (even if it's one i impatiently desire).
to achieve this i consider the following steps:
- unify text, files and images to one hybrid content structure. this way, any new item can be added without patching the database.
- simplify access control by providing convenience methods that sort out a user by verifying the necessary permissions with the actual role privileges. a developer should be able to do this with one or at most two function calls from an arbitrary action.
- rework the whole internationalisation engine. here too, a developer should only need to call a simple message funktion. and user's probably should be able to edit message files from within their site environment.
- improve skin handling and editing. as gobi already shows there are ways to shift the input (i.e. editable forms) and output skins towards each other. wouldn't it be amazing to only edit one skin once and both, your text editor masks and the user front-end appear just right and in sync?
- while we are at it: of course, antville could do with an appropriate dose of (not so) recent hot web features. well, i did not say "trackbacks" or "tags", but let's see what makes sense, here, anyway. (tags for sure!)
- while rewriting the code helma 2.0 will evolve and hopefully new accomplishments can be reflected in antville just in time.
but to be honest: just as the last years have proven i, personally, hardly see any perspective to support another developer community now or in the near future. no empty promises, anymore.
because praschl asked, somehow rightfully, if not knowingly: "why further developing antville", i'd like to promote kris' idea of (ab)using donald knuth's versioning scheme, emphasizing that antville six apart from other blogging tools is a product with limited capabilities; it does a bunch of things, and these pretty well, but it won't get all the nifty stuff automagically just because it was mentioned on technorati. (but it can if somebody is willing to write an appropriate module.)
thus, let antville's version number grow towards φ the greek letter "phi" and the mathematical symbol for the divine proportion.