Roadmap

There comes a point where the complexity of a workflow requires that you do your editing in some form other than a flat .ini file. CSV is a good one for getting data into and out of spreadsheets, which work pretty as a "design tool".

Not high priority, but "fun" - this one is to use the engine in combination with an email list for a really slow-motion long-running workflow.

This part will add a script somewhere that'll make it easy to get flow.cgi working properly.

Move everything into native packages. I've found a path that lets me rpm- and deb-ify gems fairly easily, so I'll be providing them on this site 'til they get a proper maintainer. I'll leave the option to do the install script as well, as imho there are merits to either approach (native packages & platform-agnostic libraries like gem and cpan).

I've got some debs and rpms in svn now, but they're untested. I *know* that the rpm ones are not correct - they need to be re-built. I suspect that the debs are correct for ubuntu 7.10 at least.

My thinking now wrt TheHat itself is that it'll be two pkgs: 1 for the library parts, which will be gems + native package versions thereof, and 1 for the frontends and other stuff as it comes up (e.g. configuration helpers, etc)

Some logic to help set up bot .ini files and corresponding data and web directories, where the latter will benefit from the work in phase 2

Milestone: Process type owners

No date set

50%

Number of tickets:
closed:
1
active:
1
Total:
2

There's a definite need to have owner types that spawn and wait for processes to finish. I think the underlying logic would be usable for the pre- and post- execution process hooks as well. Trick is as I've looked at the code I'm seeing that some kind of serious re-factoring makes some sense: the concept of the owner should be abstracted - so there'd be a base class representing a human (computer does nothing), and then a sub-hierarchy for the clock types and for the process type.

This is probably next on the list.

It'd be really nice if there was something like kivio or dia that could generate some file that I could use to generate workflow definitions. I looked into kivio for this once. Kivio really is a great tool. The problem is that its file format (xml) is absolutely byzantine, and yet, when it comes down to it the text inside of a box or circle or whatever is free-form. So you can't get away from having to know all the various fields the TheHat supports - about the only thing it alleviates is the tedium of connecting steps and gates together.

A kivio/dia like ui would be nice for e.g. release procedures etc. - these can be structurally complex, but not particularly time-gated, so they're more a question of just putting together complex gating.

There might also be a place for some kind of interface with a project management tool like task juggler or dotproject. The ability of thehat steps to have clock based owners combined with the fact that users can easily interact with and alter the workflow's state kinds of suggests (to me anyway) that some kind of bi-directional dialog between thehat and a project planning/management tool would be very useful. One could design ones project in the project management tool, then actually make it "live" by having thehat "run" it. There are many shared concepts. TheHat does not have a concept of "partial completion" at the moment however - that might be a necesary addition to really flesh this idea out. How to actually implement this is something that eludes me at this time.

Not currently a high priority, but interesting and there might be some demand: The engine embedded in a server daemon that handles a collection of tcp sessions. The protocol into and out of the engine is very simple as it is - basically line in, line out. A stand alone server like this opens use of the engine up to other languages, and makes the idea of a multi-protocol frontend look much more reasonable (the engine would just deal with workflow - those things connecting to it would deal with bridging). Though, in a real sense the fact that the bot has an XMPP frontend now arguably makes the engine multi-protocol anyway, as xmpp has it's own bridging.

The entire engine should be capable of being run as a web server. It should be possible to interact with the engine as if one were at a command line. It should be possible to enable and disable other communication mechanisms e.g. irc, jabber. And it should be possible to view and interact with the workflow digraph from this interface.

I'm starting to think that the whole .ini thing is kind of janky. There's a lot of impetus behind yaml - that may be the place to go. Further - it's probably the case that the config mechanism has an underlying abstraction that could just make the format a plugin thing.

Note: See TracRoadmap for help on using the roadmap.