proposed erlang/ubf application: SOW Open Workflow system
Sat Jan 29 06:50:05 CET 2005
> I think the state of UBF is that it needs some
> rethinking in order to get further
Well maybe I'll explain what I want to do and that
might inspire some of the required rethinking.
I had this idea for a Bridge bidding practice thing.
Then I saw how it could be generalized. Then I saw
that the generalization was a workflow system. So
let me explain the particular case, then the general.
If you do a simple minded bridge bidding practice
system then the two partners take turns (as they
would when playing) and each has nothing to do when
the other thinks. So what you want to do is have
multiple practice hands being bid at once so that
each can think on some, while the partner is thinking
on others. So imagine we have 16 at a time. Our user
interface will have 16 tabs. The visible part of the
tab will be green if it is our turn to bid, and red
if it is partner's turn to bid.
When partner goes off to attend to more important
matters, we make a bid where it is our turn and all
the tabs go red. So now we want to go up a level and
select a different activity. When we go up we see that
the simultaneous chess tournament has turned green.
That means that it is our move in at least one match.
We enter the tournament and see that most of the tabs
are red but a couple are green, and we go to those
matches and make moves.
While this description has been about playing
asynchronous games, it is really about having a workflow
system. From the point of view of the individual that
1. We don't have to remember what are the activities we
have to work on. All activities where we must/may/might
act are in front of us.
2. We don't have to go checking on activities to see if
they are waiting for our action. The system leads us to
the actions where we can act.
People use e-mail as a primitive workflow system. It
would make sense to have a workflow based interface to
e-mail. Using e-mail as a workflow system is horrible.
Computers get better at multi-tasking. We take human
multitasking too much for granted. It is time we gave
it more support. Well I certainly feel the need for more
A few brief comments on my workflow system before getting
to the implementation issues.
(A) There is a hierarchy: a tournament has matches, a
match has sets, a set has games, a game has points, etc.
(B) Colours don't usually alternate, e.g. in the game
Diplomacy everyone starts a round green, then when
everyone has moved we go to the next round. The only
rule is that at least one player must be green in a
live game. There can be other colours to indicate
invitations to make non-essential moves.
(C) In any particular game the players have roles and
the game has state and what the player sees is entirely
determined by knowing the players role and the game's
state. However new roles can be invented as the game
goes along and players come and go, and the state can
include components which are effectively bits of code
so that the rules of the game can be made up as we go
along. Not that I'm planning games/activities like that
(D) In the discussion above the players have been
people. In actual application they would often be
computer software systems. Indeed I envisage that a
large subset of modern network software should interface
through a workflow system instead of demanding that the
user pay attention to them or come back periodically to
Well I originally created my bidding practice system using
a html interface that was generated on the fly in Erlang.
But of course that doesn't have the right level of
interactivity for a workflow system. It was important that
the client connected to the server, but the server needed
to send messages to the client that weren't responses to
client requests. Beep is one answer but it was a bit too
tricky for me, and also lacked an Erlang implementation.
I guess I knew that the right answer is to just do a tcp
connection and exchange XML messages, but I'm not very fond
of XML. [Actually I've been investigating the idea of using
the jabber protocol, and that is still a good option:
ejabberd is in Erlang, there are jabber client libraries
for various languages and the XML messages can be made to
hold the sort of info I need.]
A key feature that I want to eventually have in my workflow
system is automation. For example in my bidding practice
system I should be able to say "the next time it is my bid,
if partner has bid 1H or 1S then I'll bid 1NT". Or if I'm
using the interface to install software on one machine then
I can reuse my responses to install on other machines if the
computer asks the same questions to within a specified margin
of error. So I want to be able to interpose a "software
secretary" into the interface.
Different games/activities will have very specific user
interfaces. However we want to have a high level description
of the interface. Various options can then be provided for
turning that interface into something the user sees (or hears),
or the secretary can understand it and try to deal with it.
by the way the project will be called SOW (for Smart Open
Workflow). It was originally COW but my employer didn't want
it. Anyway a sow with multiple little piglets is a better logo
for a workflow system.
Well there is a lot more to the design. It could be the Erlang
killer app. It could fit in well with the existing major erlang
apps: ejabberd, yaws, btt, not to mention telecommunications
stuff. If other people want to contribute then I'll be happy to
start a sourceforge project. Let me know what you think.
More information about the erlang-questions