Discussion Thread

[Ivan R. Judson]

I think considering @who and @page are critical to think about venues
requirements. We also should consider the following scenario:

I have two venues A (which is configured with a Voyager Service) and B
(which knows nothing about the Voyager Service).

In Venue A, I record some interactions and get a reference to a
recording, R. I carry R, to venue B. How do I play it? I can't right?
What if I wanted to introduce the Voyager Service to Venue B. How is
that done?

--ivan

PS -- I vote for 2.0 no @page or @who, too many tentacles in the system,
too little time to untangle them.

..........
Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
Futures Laboratory .~.  630 252 0920
Argonne National Laboratory .~. 630 252 6424 Fax
 

> -----Original Message-----
> From: owner-ag-dev at mcs.anl.gov 
> [mailto:owner-ag-dev at mcs.anl.gov] On Behalf Of Terry Disz
> Sent: Thursday, September 12, 2002 11:28 AM
> To: Rick Stevens; Ag-Dev at Mcs. Anl. Gov; Hereld at Mcs. Anl. Gov
> Subject: RE: Discussion Thread
> 
> 
> Yes, exactly, these ideas are consistent with the metaphor. I 
> don't think that is controversial. People will want to 
> organize things in these and other ways we probably haven't 
> thought about yet - it is an area rich with possibilities. We 
> may provide some of this kind of organization ourselves, but 
> mainly I believe we should simply accommodate others who want 
> to do so.
> 
> The questions I have are: Have we thought about the impact of 
> these requirements? What must a venue provide to accommodate 
> people wanting to organize things in these ways? Or, for that 
> matter, should a venue make any accommodation at all? Are we 
> prepared to answer questions from AG users who clearly want 
> to be able to do this? What lessons should we take from web 
> pages and web page linking, discovery, etc? (Venues, after 
> all, are not web
> pages)
> 
> I think a discussion of these is interesting, and perhaps 
> should include how closely we want to stick to the 
> constraints of the real world in our analog. For instance, 
> should we allow the MUD equivalent of an @who? Or a PAGE? (I 
> think maybe we should) If so, constrained by what scope? 
> (That, I dunno).
> 
> Just wondering,
> 
> Terry
> 
> > -----Original Message-----
> > From: Rick Stevens [mailto:stevens at mcs.anl.gov]
> > Sent: Thursday, September 12, 2002 4:38 AM
> > To: Terry Disz; Ag-Dev at Mcs. Anl. Gov; Hereld at Mcs. Anl. Gov
> > Subject: Re: Discussion Thread
> >
> >
> > I think we need multiple ways of addressing this.
> >
> > Search engines
> > Directory Services
> > Maps (overlays that provide navigable links to multiple 
> venue servers) 
> > Public Plaza's that folks can connect too.
> >
> > I dont see any of these as being inconsistent with the 
> metaphor.. in 
> > fact we have equivalents of all of these in the real world
> >
> > At 11:48 PM 9/11/2002 -0500, Terry Disz wrote:
> > >This mail list ought to be good for more than just sending
> > attachments, and
> > >since we are all having a hard time being in the same place at the 
> > >same time, I thought I would try and start a discussion thread.
> > >
> > >What I want to discuss is scalability, in terms of what do we do
> > if the AG
> > >becomes really successful and there are bazillions of venues, or 
> > >more. I think this discussion is important because any possible 
> > >solutions go directly to Venue requirements and I don't want us to 
> > >miss a requirement because we didn't think hard enough about this 
> > >problem.
> > >
> > >So, here's the issue - we at Argonne have been promoting the idea 
> > >that venues should be linked with door-like objects, and we can 
> > >navigate from venue to venue, just like the MUD. Although 
> this can be 
> > >fun, and can be interesting in a social-experiment way, 
> it's easy to 
> > >see that
> > this doesn't
> > >scale very well when we start to talk about hundreds, let alone
> > bazillions
> > >of interconnected venues. Without structure, it would 
> quickly become 
> > >impossible to find things and use the venues to conduct business.
> > >
> > >Although we have a stake in this idea, I think it might be a
> > little wobbly
> > >and I wonder if we shouldn't be talking about alternatives, or at 
> > >least about ways of imposing or discovering structure  in 
> a network 
> > >of linked venues.
> > >
> > >Looking to some of our users, I know of at least two who operate 
> > >venue servers that have just a list of venues that users 
> can choose 
> > >and be directly ported there. This idea of an index on a set of 
> > >venues
> > and a method
> > >of jumping directly to one seems to be attractive to some. I know, 
> > >transiting venues is a fairly heavy operation today, but I think
> > the problem
> > >goes deeper and these other solutions would still exist even if
> > transiting
> > >were fast, as with the MUD today.
> > >
> > >Other ideas on what to do for scalability are;
> > >1. dispatch venue-discovery bots to create a database to answer 
> > >google-search questions 2. Create a set of Yellow pages to 
> help find 
> > >venues by purpose. 3. Create a set of white pages to help 
> find venues 
> > >by name.
> > >
> > >
> > >Put on your thinking caps -  what about scalability? How do we
> > provide it?
> > >What requirements do these solutions have for the venue? What are 
> > >your ideas?
> > >
> > >Terry
> >
>