another Workflow system

[Joe Armstrong (AL/EAB)]

What fun - before you can make a UBF spec (which might be overkill) you
have to decide on an architecture and model the data structures you need.

Here's a few thoughts on this:

Architecture 1 - centralised server

First we need a model of the conversation.

Id rather like to see this:


          +-------------+
        +-------------+ |
	+-------------+ | |
      |  SS  |  SW  | | |
      |-------------| |-+
      |  OS  |  OW  |-+
      +-------------+

This your diagram but with a time axis - ie I'd like to see how
the argument state changes with time - the top of the stack is the current
state of the argument - each stack frame represents a snapshot
of the argument at a particular time.

On a centralised server we can model everything as

	all_arguments => [id]
		
          list of all arguments in the system. Each argument has a unique Id
      
      argument[id]  => {userId1, userId2, [{What,Time,Str}]
	    
          The individual arguments - UserId1, UserId2 are (Self and Other)
          What is ss, os, sw or ow ie which part of the argument has changed

	notify[UserId] => [Id]

	    a notification array - for each user this has a list of Id's of the arguments
	    which have changes since they last modified the argument

 The client protocol is easy:

	First authenticate the user (say using challenge/response and a shared secret)

  	Then send {update,Id,U,What,Str} messages to the server

	Id = the argument Id, U = the authenticated user, What is one of ss,os,sw or ow

The server updates the argument[Id] entry and adds Id to notify[U1] where U1 is the other
person in the conversation. It removes id from notify[U] if it were present.

Now you have to make some design decisions. How should we store these conversations? - these
are design chooses:

	- One per file
	- Everything in one file
	- Everything in dets
	- Everything in mnesuia
	- Everything in an external data base etc.

I'd start with the simplest (one per file, and use term_to_binary etc.  :-)

Then the interface - emacs is fine but scary for naive users.

Id use yaws (for form generatation) + an embedded JavaScript rich text editor

<< aside www.kevinroth.com/rte/demo.htm is great for this.

   BTW if anybody is interested I have made several changes to this editor
   to beautify the code if you are interested mail me
>>

You could easily make a form (in yaws) with four squares in it with
a wysiwyg RTE editor in each and a Send button.

Then you need a bit os stuff for account creation - this is (I think) included
in the yaws distribution.

Architecture 2

Is like 1 but you make a hot standby/failover node

Read my http://www.sics.se/~joe/tutorials/robust_server/robust_server.html   to
see how to do this (this uses a replicated mnesia data base)

Architecture 3

Umm - peer to peer - keep the conversations on the peers. The
server now just maintains list of the hostnames of all the users etc.

This is beginning to get tricky since there are no of-the-shelf
P2P infrastructures that can be used for this.

<aside>

One interesting sub-project might be to create such an infrastructure for Erlang.

Idea (Off the top of my head so probably nonsense)

Distributed Erlang is just too dangerous to use in a P2P system
(rcp(Node, os, cmd, ["rm -rf *"])) :-)

But a simple socket server with an allowed set of services is
safe.

Imagine that each participating user sets up a socket server
on a well-know port (1234) (the Erlang port)

This port accepts Erlang terms and replies with Erlang terms
(or xml or http) - (I have such a program) - the user configures
which services they will permit on their machine.
I have code for this :-)

So far so good - how do the machine discover each other?

Answer - use SIP

There are (I am informed) publically unavailable SIP servers -
we could use the notification and location services to
inform when we go an and off line.

Then we need a few well-know SIP addresses to bootstrap the system

(BTW if you want to comment on this please start a new thread
called P2P in Erlang) so as not to confuse Lyn's argument)

</aside>





> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Lyn Headley
> Sent: den 1 februari 2005 07:33
> To: Bob.Smart@REDACTED; erlang-questions@REDACTED
> Subject: another Workflow system
> 
> 
> Hi Bob,
> 
> your workflow system reminds me of the system I'm working on,
> although not exactly. My system facilitates 2-party "complex
> conversations" (it's designed for working social theorists, e.g.
> professors, grad students, etc, but should work for any kind of
> complex conversation). right now it's a quick and dirty
> distel/erlang program looking for a more robust network semantics
> and backend. the idea is that a conversation consists of a series
> of topics, where a topic is displayed in an emacs frame and
> contains 4 buffers called perspectives, which represent positions
> in the evolving argument/dialogue. 
> 
> like so:
> 
> ----------------------------
> | self-strong | other-weak |
> |---------------------------
> |other-strong | self-weak  |
> ----------------------------
> 
> where self-strong is my position, other-strong is your position,
> self-weak is my reply to your position, and other-weak is your
> reply to my position. then at any time i can either
> 
> 1) rewrite self-strong
> 2) rewrite self-weak or
> 3) create a new topic.
> 
> now here's where the workflow comes in. once we've got two (or
> more) topics going we'll have several fairly independent lines of
> dialogue going. Thus I may be writing a reply on topic one while
> you update topic two. The difficulty for my system is that,
> although it is useful for the system to inform me when my partner
> has made a "move," this doesn't mean my partner must wait on my
> reply before moving again. in fact, if I make a change and don't
> like it, I can just change it again. So I suppose my system needs
> something like an event notification engine, rather than the
> strict turn-based ordering you can rely on. But I like the tabbed
> interface idea with Green and Red indicating the "needs
> attention" status of the tab. And I'm thinking of going over to
> UBF at some point too. So i'll be curious to see where your
> project heads.
> 
> best,
> Lyn Headley
> 
> 
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> The all-new My Yahoo! - What will yours do?
> http://my.yahoo.com 
>