Entries tagged 'colobus'

A reason that I finally implemented better thread navigation for the PHP mailing list archives is because it was a bit of unfinished business — I had implemented it for the MySQL mailing lists (RIP), but never brought it back over to the PHP mailing lists. There, it accessed the MySQL database used by the Colobus server directly, but this time I exposed what I needed through NNTP.

An advantage to doing it this way is that anyone can still clone the site and run it against the NNTP server during development without needing any access to the database server. There may be future features that require coming up with ways of exposing more via NNTP, but I suspect a lot of ideas will not.

Another reason to implement thread navigation was that a hobby of mine is poking at the history of the PHP project, and I wanted to make it easier to dive into old threads like this thread from 2013 when Anthony Ferrara, a prominent PHP internals developer, left the list. (The tweet mentioned in the post is gone now, but you can find it and more context from this post on his blog.)

Reading this very long thread about the 2016 RFC to adopt a Code of Conduct (which never came to a vote) was another of those bits of history that I knew was out there but hadn’t been able to read quite so easily.

Which just leads me to tap the sign and point out that there is a de facto Code of Conduct and a group administering it.

I think implementing a search engine for the mailing list archives may be an upcoming project because it is still kind of a hassle to dig threads up. I’m thinking of using Manticore Search. Probably by building it into Colobus and exposing it via another NNTP extension.

Because there’s nothing that quite says “hire me” like polishing your Perl bona fides, I have finally made a new release of Colobus, the NNTP server that runs on top of ezmlm and Mlmmj mail archives. (It was actually three new releases, I had to work out some kinks. More to come as I work out more in testing.)

The Mlmmj support and some of the other tweaks are really just pulling in and polishing changes that had been made to the install used for the the PHP.net mailing lists. There are also a few bug fixes I pulled in from Ask’s fork of colobus that the perl.org project uses.

I did add a significant new feature, which is a non-standard XTHREAD id_or_msgid command that returns an XOVER-style result for all of the messages in the same “thread”. The code to take advantage of this new feature for the PHP mailing list archives is on the way.

i created a google code project for colobus and imported the old releases into the repository. i’m not a huge subversion fan, but it didn’t make much sense to stick with bitkeeper with no free version available, and making system administration google’s problem seemed like a good thing.

i’ve folded in a couple of patches that were sitting in my inbox, and have another bigger one to put the group information into the database.

i popped out a new colobus release. nothing exciting, just some performance tweaking to take better advantage of the database back-end.

i’ve released version 2.0 of colobus, my nntp server that runs on top of ezmlm archives. there’s more that could be improved, but this at least gets an initial DBI-driven version out there.

i tried to announce the release on freshmeat, but it kept timing out. we’ll see if it takes.

i was all ready to write an blog entry about an upcoming release of colobus (my nntp server for ezmlm mailing lists), when i happened to look at one of my terminal windows and notice a very bad rm -rf colobus*. uh, oops.

i’ve recreated the changes (the hard part was writing it the first time), now i just need to do more testing to make sure i really did recreate the changes. putting the 165,478 messages from the mysql general mailing list into the database takes a while.

i also have (and did not accidently delete, at least not yet) a replacement for most of the rest of the bits of the web-based archives that are currently served up by ezmlm-cgi. which for lists.mysql.com, is just the listings — i already replaced the message view with code based on the lists.php.net code.

it handles the encoding of the posts to the japanese users list (unlike the current ezmlm-cgi listings), which is cool, even if i can’t understand it. it also handles that wacky Antwort prefix the germans love so much.

i should really package up the web frontend stuff someday, too. there’s really not much of anything specific about the lists.mysql.com setup to it. it just mimics ezmlm-cgi right now — i need to think more about how i really want it to look and work.

it has been over two years since the last release of colobus, my nntp server written in perl that runs on top of ezmlm archives. this new release just incorporates a couple of accumulated bug fixes and tiny features.

i have a proof-of-concept version that uses a mysql backend. i’ll get that code folded in and cleaned up and make a 2.0 release some day.

i know the by-date archiving needs to use the time that the mail actually arrived to the server, or you get the sort of oddities that mailman archives get. by-month, threaded archives don't scale particularly well for busy lists. i'm not a big fan of the ezmlm-cgi-style list of threads with links to the latest post. do you want a single message at a time, or multiple posts from a thread at a time, google news-style? (with frames?) i think there's something to be said for a simple list of the most recent posts, with no threading. (but perhaps sorted with the newest at the top is better?) i think displaying the message thread with each message is a must-have feature. i think doing some intelligent coloring of quoted passages is a really neat feature. so is intelligent handling of attachments. using jwz's threading algorithm is probably a good idea (although i would probably use a database to store the results). obviously encoding or obscuring or omitting email addresses in message headers is a good idea, and it's probably a good thing to do in message bodies, too. being able to get the list of messages from a particular author is a nice feature. closing the loop by making it possible to reply to messages using the web interface could satisfy desires for web-based forums. setting up a nntp server is obviously a good thing to do, too.

(yes, this is obviously a work-related musing. don't get too excited, it's not a high-priority item right now.)