proposed erlang/ubf application: SOW Open Workflow system

[Bob.Smart@REDACTED]

> 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 
means:

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 
support!

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 
yet.

(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 
check them.

--------------------------------------------------------

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.

Bob