List Info

Thread: Bouillon 2 project




Bouillon 2 project
user name
2006-06-21 09:14:41
Hi!

Yesterday I've launched first public Bouillon server. It is
relevant  
to Jabber because it uses XMPP as a transport, it also uses
rosters  
as a material for building social network (in plain words,
in reuses  
existing IM contact social network). Bouillon functionality 

intersects with Jabber whiteboarding and Jabber wiki
initiatives.  
Current Bouillon connects to a Jabber server as an external 

component. Client side is implemented in AJAX.

In two words, Bouillon is "editable Web". In
four words, "P2P wiki  
with reputations". In more detail:

- Bouillon allows P2P editing of arbitrary XML (XHTML for
now). But,  
there are no single global version of any page. Each user's
agent  
retrieves and assembles pieces of a page from user's
friends, friends- 
of-a-friend, etc
- If Bouillon user likes a page or a new piece of a page or
a new  
version of an existing piece (i.e. considers it relevant)
then (s)he  
may confirm that page/piece (i.e. issue an opinion) and let
it  
propagate further in the social network
- If a Bouillon user considers a piece to be trash/spam then
(s)he  
may suppress propagation of that piece issuing a negative
opinion.
- Users may edit existing pieces or insert new pieces using
their Web  
browsers or any other client if implemented.

Pieces are identified by POV IDs, i.e.
parent_id/own_id:version_id.  
An example:
	Bouillon_Manual-root/EditingTherearethree:author=foafoc- 
co.org,created=1150784880293
It means: "Editing" section at
"Bouillon_Manual" page, version by  
foafoc-co.org created on Tuesday, June 20th.

To see that piece and the whole page a Bouillon user has to
visit  
http
://some.bouillon.server/page/Bouillon_Manual, so it is
much  
analogous to wiki. Realtimeness of Bouillon is currently
limited by  
AJAX client which polls a server every minute or so;
otherwise,  
changes may propagate in real time.

Technically, Bouillon engine uses <iq> to send
requests/responses  
back and forth. User information and roster is obtained from
a server  
using simple jabber login having -1 priority.

I consider the core algorithm of Bouillon, the oc-co
asynchronous  
switching engine, as mature. Theoretically, it may process
any XML  
content, e.g. SVG. The code itself is released under GPL,
see http:// 
oc-co.org.

So finally, I am currently considering possible Bouillon  
applications. In particular I think it worth discussing in
regard to  
Jabber-driven real-time wiki and Jabber whiteboarding
initiatives.


		Yours,



					Victor Grishchenko
					research fellow
					Ural State University


					see project blog at: http://oc-co.org
					Bouillon public server: http://oc-co.org:8000
Bouillon 2 project
user name
2006-06-21 10:01:59
Interesting,

correct me if I'm wrong but it seems to me that Bouillon
would be
suitable for editing the kind of "long term"
whiteboards that aim to
illustrate something that's relevant in the long term and
can be
improved by different users. E.g. a mind map.

However, for "real time" whiteboarding where a
user aims to share an
*instant* message in the form of strokes on the whiteboard
Bouillon
doesn't seem so suitable. E.g. a user wants to write on the
board in a
script that's difficult to write with a keyboard or share
mathematical
formulas or driving or other directions. In these cases each
user must
get an identical view of the whiteboard and it's not
necessary to
store it on a third party server because the whiteboard
doesn't have
any long term use.

I can't say I understand Bouillon very well so I can't
estimate at
this point if these two types of whiteboards could share
parts of
their protocols. Is there any publically available
documentation of
the Bouillon algorithm or only the source of the oc-co
asynchronous
switching engine?

Joonas
Bouillon 2 project
user name
2006-06-21 10:23:47
On 21.06.2006, at 16:01, Joonas Govenius wrote:
> correct me if I'm wrong but it seems to me that
Bouillon would be
> suitable for editing the kind of "long
term" whiteboards that aim to
> illustrate something that's relevant in the long term
and can be
> improved by different users. E.g. a mind map.
You are right. Although Bouillon has real-time features, it
assumes
long-term storage.

Another difference: Bouillon assumes no pre-given
participant
list. The circle of participants is vague, it is some open
"social
vicinity".

> it's not necessary to store it on a third party server
because the
> whiteboard doesn't have any long term use.
>
> I can't say I understand Bouillon very well so I
can't estimate at
> this point if these two types of whiteboards could
share parts of
> their protocols.

I'll think about it. Do current whiteboarding
implementations
implement content assembly? Do end-points exchange diffs
or snapshots?

> Is there any publically available documentation of
> the Bouillon algorithm or only the source of the oc-co
asynchronous
> switching engine?

Sorry, now I have a bit of docs in Russian, even less in
English.
Simplifying a bit, it happens this way:
A user's agent sends page root request (/Bouillon_Manual)
in
all directions; friends relay it until resource limitations
permit.
All peers who have their own or store someone other's
opinion
reply with root opinions.
When root opinions are obtained, user's agent starts
"climbing".
It recursively requests opinions on kids from anyone who
sent
him opinion on the parent. This way it retrieves all
opinions
available in some social vicinity. So, at this stage
requests are
directed, no blind flooding.
If opinions on some piece are positive then the piece's
body is
retrieved.
All that activities are implemented in asynchronous fashion
to
have no out-of-order or timing issues in such a distributed
system.


					Victor
Bouillon 2 project
user name
2006-06-21 10:40:16
> Do current whiteboarding implementations
> implement content assembly? Do end-points exchange
diffs
> or snapshots?

The current implementations are all undocumented and differ
quite a
lot but that's why I'm working on a Summer of Code project
to draft a
JEP that defines a common protocol. I have a draft already
that
specifies how to share a whiteboard, except how to handle
users that
join in the middle of a session. I'm suffering from slight
"logistical
problems" right now though so I can't make it
publically available but
I'll let you know as soon as I do put it online. Hopefully
today or
tomorrow.

Joonas
[1-4]

about | contact  Other archives ( Real Estate discussion Medical topics )