I was planning to release PInetd2 as soon as PHP 5.3 gets stable (which will maybe be the case with 5.3.1 ?), until it happens I’m adding new features and fixing bugs.

I’ll start with something I already coded (NetBatch) before introducing the new feature I’m working on (Transports).

NetBatch

NetBatch is a new daemon allowing to run applications on a local or remote server. It has many possible uses, since it even allows running stuff as root, or run stuff in background.

With NetBatch, reloading apache’s configuration, restarting a server, etc… from an apache process is no longer a dream. You can just connect to whatever server you want, and run the stuff. NetBatch is running in async mode, meaning you can even run interactive applications and provide input when you feed the need to.

NetBatch also has a different operation mode, named “Persistent”. It allows you to run a (potentially long) operation, and connect later to get the result. You have to poll the application (or NetBatch will kill it), and you can control it like a normal application. The only difference is when you disconnect/reconnect, the application is still there.

Transports

Transports is a new feature allowing implementation of read/write resources. The two first transports I’ll implement are IRC and RSS. Both will provide some kinds of resources (irc_channel, irc_user, rss_feed) and the ability to read objects/write objects on those.
rss_feed will be a read-only resource providing rss feed polling. irc_channel will be a read/write resource allowing to control a generic bot on (a) given channel(s). irc_user will provide full control over the bot, private messages, etc (and will cause a dedicated connection).

Other transports are also planned, including but not limited to jabber, twitter, msn, etc… (anything that can emit or receive “events”).

Configuring a transport is done via an XML node. Each transport will have its own settings (for example “refreshTime” for rss_feed), and will have a “connected state”. When a transport is “connected”, it may have a separate process launched handling the connection.

Transports are handled using pinetd2′s internal IPC system, however they don’t require polling to work. Once connected, incoming data will be sent directly from the transport, as soon as it is made available.

The goal is of course to allow creation of various things with pinetd: bots, notifications, etc

Future

One of the biggest missing features in pinetd2 is an administration interface. A way to view logs, start/stop daemons, edit configuration, etc… I’m planning to do this using pinetd2′s HTTP daemon, and started up to some extent, but haven’t found anyone to help me by working on the HTML interface (I’m really bad with HTML).
Once pinetd2 gets an administration interface, I’ll be able to go through the documentation process before starting a release cycle (RC, then release) to finally get a stable release of pinetd2.