I've checked in a patch to weblog/search.hac that escapes single quotes in search strings. This may or may not have been a security problem (if it was, I wasn't able to exloit it). Anyway, antville.org is running the updated code now. This is a temporary patch since I'm currently rewriting the search function to be more flexible, including the capability to search the whole site/server instead of just one weblog.

O'Reilly is preparing a book on "essential blogging", which just has entered public reviewing. It seems that Antville has been neglected so far.

i have some problems on my server because some users have messed up their main skins with either recursive calls or by deleting the macro for the response. first question is how can i fix this easily? second question is about avoiding future problems. can you use the default template for the skin manager ? i think the skin manager should be available even if the user makes mistage with the main skin.

Finishing timezone support for Antville was pretty painless - all I had to do was make sure that date parsing and formatting are always done through parseTimestamp() and formatTimestamp() functions, which take in account the local weblog's localisation and timezone, if a weblog object is present in the request path. All dates are still stored in local server time. Both parseTimestamp() and formatTimestamp() are in global now, although weblog.formatTimestamp() is still there for backward compatibility - I didn't want to go through all the code - but all it does now is to forward the call to the global formatTimestamp() function.

The fact that the weblog object for date localization is always taken from the request path (i.e. path.weblog) causes one significant change: If an object from one weblog is used from within a page of another weblog or the application root area, the language and timezone from the embedding environment will be used for rendering dates, not those of the object's home weblog. In my opinion this makes sense because with timezone support, dates would not only be rendered in a strange language, but could also be a few hours off, i.e. you'd see dates in different timezones mixed together in one page. However, if this functionality is needed, it would be possible to format dates according to their home weblog by passing either the weblog or the locale and timezone to the formatTimestamp() function.

Finally, I implemented caching of java.text.SimpleDateFormat objects. These things are pretty expensive to create since the format has to be parsed each time. On the other hand, reuse is difficult because the class is not thread safe and would produce broken output if used by multiple threads at the same time. My solution is to cache them in the res.data object, using the format string such as "short", "yyyyMMdd" etc as key. front page rendering is now about 10% faster, and the gain could be even larger for pages with many dates.

Right now, the changes are still in the hns_timezone branch. I'll test some more and eventually merge changes to the main branch if that's ok.

I'd continue working with timezone support now if that's ok and go on streamlining date time rendering. I've checked and this does not interfere with Tobi's work, but I don't know what Robert is up to so I thought I'd ask before I start.

just to deposit a thought i had right now:

wouldn't it be cool if the usage of images (and in the future also stories...?) in other weblogs via a macro like <% image name="tobi/barbes" %> would be logged / displayed in the original weblog?

this way one could keep track of where else one's material is used (and you get some more related links, too).

just for the records: i made a huge step forward in rewriting robert's cool image_macro (here's the code in a cvs branch of antville, third function from top).

the features of thumbnail_macro() and imageurl_macro() are now included by handing over param.as = "thumbnail" or param.as = "url". well, to be honest, param.as = "popup" does the job of the thumbnail macro, while param.as = "thumbnail" does almost the same just without popping up a new window using javascript... (good?)

moreover, i started to modify some of the global renderSomething() functions: the problem was that they are hardly re-usable due to many res.writes in the code. so i renamed these functions to renderSomethingAsString() and replaced the direct output by building a string and returning it in the end. then, i added new functions with the old name as wrappers to directly write out the result of the --AsString() functions again. while it sounds complicated here, i think it becomes quite clear when you think of renderSkin and renderSkinAsString...

is that a way to go? would you support this code structure?