[AG-TECH] Idea for creating "observer only" venues

[Ivan R. Judson]

Seems like just using some authorization facility would be easier. Just
don't allow those participants to "write" to the venue.

The authorization stuff that's in 2.X is admittedly incomplete and the SOAP
latency makes it hard to use, but it's proven itself when it comes to the
design and structure. In 3.X we'll have to make sure it's fast enough to be
usable because with it you could do what I'm describing, which is what you
really want. you don't really want to bridge venues this way, it's plumbing
at the wrong level of the system, IMHO.

--Ivan 

> -----Original Message-----
> From: owner-ag-tech at mcs.anl.gov 
> [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Frank Sweetser
> Sent: Friday, October 22, 2004 6:42 PM
> To: ag-tech at mcs.anl.gov
> Subject: [AG-TECH] Idea for creating "observer only" venues
> 
> While sitting in on my local node SC global certification 
> run, the difficulty of encouraging people with personal nodes 
> to come in and observe events while simultaneously ensuring 
> that everyone in a given event is operating their node 
> properly was brought up.  While thinking about it later, I 
> came up with at least a potential solution - a one way bridge.
> 
> Take two venues, A and B.  A sizeable event is scheduled in 
> venue A that will have a fixed set of predetermined 
> interactive participants, but the event coordinators would 
> also like for anyone who wishes to be able to view the full 
> event.  My idea is to take a hacked up bridge that connects 
> to both venues A and B, but only forwards multimedia 
> multicast traffic and any other events (such as shared app 
> events) from A to B, and ignores any events that it sees from 
> venue B (although exceptions might be made - question tool, 
> for example).
> 
> The end result of this would be that everyone in venue A 
> would see and hear each other, while those in venue B would 
> see and hear everyone in venue B, plus those in venue A.
> 
> Does this sound reasonable?
> 
> --
> Frank Sweetser fs at wpi.edu
> WPI Network Engineer
> GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC
> 
>