One framework to rule them all

I have a love/hate relationship with PHP; while I have talked in great length about all the badness that comes with it, I still find myself quite often writing and / or contributing to PHP applications. Most of this work was done with Symfony and, to a smaller degree, recently also with a relatively unknown framework called Pluf, which is the main building block for Indefero, the project and source code management tool I’m contributing to.

The author of Pluf, Loic d’Anterroches, has released a new framework to the wild today and its called Photon. It got its name from the particle, so naturally the tag line is “…because nothing is faster than a photon”.

So you are by now probably asking “Ok, but why should I care about that? There are dozens if not hundreds of PHP frameworks out there, they all claim to be fast, so this is probably just a complete waste of time…”

Well, Photon is very different, because it achieves its performance with a break of the traditionally known request-response model: Much like a real application server you know from other languages you can process requests asynchronously now in pure PHP, i.e. start and stop processes on request and delegate long-running work for later execution!

PHP developers did all kinds of bad tricks to emulate this stuff in the past. Most of these tricks employ a cache table and a cron entry that regularily executes some PHP script. This is buggy, doesn’t scale well and is of course plain ugly.

I won’t go into more details – just hop over to www.photon-project.com, read the docs and grab the pre-release while its hot!

Monotone's new project forge officially online

I’m proud to announce that we’re almost done with one big entry in our TODO list for the ongoing server migration: Our indefero forge instance, a web-based project management software, is now set up and online under code.monotone.ca!

The forge contains several monotone-related projects, each with their own bug tracker, wiki, code browser and review module. Here is monotone’s one, and here the one for guitone. We’re planning to add more projects as the need arises and people demand them.

Each of the current and future setups also includes automatic access management for the underlying monotone repository which is served over usher – our proxy. Repositories can simply be accessed by their project name – so if you want to pull from the monotone repository, just trigger

$ mtn pull 'mtn://code.monotone.ca/monotone?*'

Please note that with the advent of indefero, the main bug tracker of the monotone project is no longer Savannah, but Indefero. All the of the existing open bugs have been imported into monotone’s indefero project, so Savannah’s bug tracker should no longer be used (we’ll leave it online for reference for a little longer, though).

So I said “almost done” – whats missing? A few things actually:

  • automatic mirroring of selected repositories with the designated mirrors
  • push notifications for IRC / mailing list updates
  • a better visual integration into the rest of our setups

While the first two things are on Richard’s TODO list, the last one is on my own schedule, though I want to wait a little longer until indefero’s redesign is through (expected sometime this fall).

And finally, the indefero monotone plugin needed a couple of extensions to core monotone, which I’ll likely blog later about, so stay tuned. If you’re interested in hosting your own monotone-related project on our forge, just drop me a note.

Thanks for reading.

mtn support for indefero got merged

It took us quite a while, but Loic d’Anterroches finally merged my monotone support fork back into indefero. Its expected that the upcoming 1.1 release of indefero is the first release which ships with mtn support.

Most of the things I talked about in the earlier blog post have now been implemented, i.e. you are now able to use remote_stdio to access remote databases or databases behind an usher instance. Furthermore, a forge-level control panel for usher and monotone public key support have been added.

The documentation has also been improved, there is a separate README file which lets you get started and the documentation on the new IDF configuration variables is also exhaustive.

What is kind of missing right now are support scripts for the forge-level setup of monotone. I plan to add these and even more documentation when I set up monotone’s new home server in the next couple of weeks. Yes, you’re reading right, monotone gets a different address, a fancier bug tracker and also a nicer revision browser (thanks to indefero) and if everything goes right, we’ll even offer monotone hosting support for selected projects.

Stay tuned for more updates!

monotone plugin for indefero (updated)

I’ve started hacking on a monotone plugin for indefero – a source code / project management tool which supports various SCM backends. You can find the code for it on github (git, because, well, indefero uses git…).

While there are a couple of web-related tools for monotone, namely TracMonotone and ViewMTN, both projects haven’t seen many updates over the last couple of years and are now even maintained by a single person who has not much time either. Having very good and broad tool support is however crucial for an SCM system, because only very few people are willing to use the command line for everything, so I hope that the addition of indefero as tool which will support monotone in one of its next versions will help both projects a little.

The code is still in alpha state, but one can already browse branches and revisions. My current TODO is as follows:

  • finalize the implementation of the changelog view done
  • make branch names shorter in the UI so they don’t overlap with the tree contents done
  • add automate stdio support for the SCM backend class, so we don’t need to create a separate process for every data request done
  • add automate remote_stdio support (possibly by adding a configuration option which allows either setup)
  • truncate the log message in the tree view to a proper size
  • dynamically change the clone url to the branch which the user is currently browsing done
  • check the inTags() and inBranch() implementations – apparently this does not work as it should done

Especially the multi-project nature of indefero requires some additional hacks in monotone and also one of its tools, usher (which is able to serve multiple distinct databases over one connection), so this plugin project really drives a lot of development. If you’re interested in either part and want to team up, drop me a note 😉