Go Gabrielle, Go !

I am totally supportive to your challenge, however I don't see that newbie
like me can be a part of it. Nevertheless I will enjoy seeing you all gurus
and Rebol jedi in  a fair and loyal joust.

Patrick



----- Original Message -----
From: "Gabriele Santilli" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 03, 2001 5:45 PM
Subject: [REBOL] A REBOL challenge - The Information World


> Hello all!
>
>  A REBOL challenge
>
> [Permission is explicitly granted to publish this document on the
> REBOL Zine, on REBOLForces or on any other REBOL-related
> publication/site/whatever.]
>
> With this message, I'm going to launch a challenge. The goal is to
> create a peer-to-peer communication system as described below;
> implementations will be judged by the members of the REBOL mailing
> list, with regards to:
>
>   * Code elegance and simplicity
>   * Efficiency
>   * Usability
>
> If my free time will permit, I'll partecipate to the challenge
> too; a time limit will be set in agreement with the participants.
> The resulting code is required to be freely distributable at least
> inside the REBOL mailing list; freely distributable software will
> be preferred over restricted software because to be useful the
> system has to be available to all the users of the Internet.
>
> [I'm quite sure Maarten will participate with a Rugby based
> implementation; I'd like to have someone doing a REBOL/IOS based
> implementation too...]
>
> If you are interested, please read the following document
> carefully; comments or requests for clarifications will be
> gratefully accepted. [Since this version can be considered a sort
> of draft, I would be vert grateful to those of you that will
> really be brave enough to read it all and offer me some comments.]
>
>  The "Information World"
>
> I want to create a sort of "virtual world". I will call it the
> Information World (IW). This world is made of informations, from
> static data to "live" entities able to interact with the rest of
> the IW.
>
> The IW is based on three simple entities that the implementation
> has to represent. These are "Places", "Objects" and "Agents".
>
>  Places
>
> A "Place" is a location in the IW. It can contain objects and
> agents, and it can be connected to other places. (The connection
> does not necessarily need to be a TCP/IP connection or something
> like that; you can think of it as a "road" going from one place to
> another. Also notice that if place A is connected to place B,
> automatically place B is connected to place A.) Agents can move
> from one place to another only using a connection (normal agents
> cannot create a new connection).
>
> The implementation of a place has to provide a way for agents to
> know what other objects and agents are present in the place. I.e.
> the agents will have to be able to query the place where they are
> to know what's there besides of them.
>
>  Objects
>
> "Objects" are "things", such as repositories, containers,
> documents, and so on. An object can contain other objects; for
> example, a book shelf object might contain book objects. By
> themselves, objects cannot move from one place to another or
> interact with other objects or agents. Only agents are able to
> iteract with other agents or objects.
>
> The implementation should make it easy for objects to be moved
> from a place to another (by agents); also, agents must be able to
> query an object to know what actions it can perform on it (for
> example, a book shelf might provide a "search" action to allow an
> agent to search for a book, and so on).
>
> The implementation has to provide an easy way for users to create
> new objects. Also, objects can be cloned.
>
>  Agents
>
> "Agents" are the most interesting entity of the IW. They are the
> key for the communication, since they are the only entity that can
> move from a place to another and interact with other entities.
> They can also carry objects, but there should be a limit on the
> size of the objects an agent can carry on a given connection.
> Implementations have to deal with security issues raised by the
> presence of agents.
>
> In particular, two categories of agents have to exist: "Residents"
> and "Tourists". The only resident agents available should be:
>
>   * The "Road Builder", which creates connections with other
>   places. It is the only entity that can create connections; of
>   course it can destroy a connection too.
>
>   * The "Sentinel". A sentinel can be placed on every connection
>   to verify the identity of coming tourists and place restrictions
>   on them or even disallow their entrance. Each sentinel should be
>   in communication with the one on the other side (if present) to
>   be able to identify coming tourists. (Identifying might just
>   mean assigning a "trust level" or something like that.)
>
>   * The "Mail Agent", which is responsible of sending (big)
>   objects to other places. The mail agents can be asked by an
>   agent to send an object to another mail agent on another place;
>   it should also be possible for mail to be delivered to a
>   specific agent in a place (passing thru the mail agent of that
>   place). The implementation should provide an efficent way to
>   transfer any amount of data. (This makes up for the limit of
>   agents to carry objects; place-to-place connections should be
>   optimized for the transport of tourists with rather small
>   baggage, while mail agent-to-mail agent "connections" might be
>   optimized for transferring big objects.)
>
>   * The "Banker". A place might have a banker which holds
>   important objects. Objects available in the place can be used
>   (and cloned) by any agent, so a banker might be needed to
>   restrict access to some objects.
>
> The implementation should not allow for a tourist to become a
> resident, unless the user explicitly wants it to (and he/she
> should be warned that this is a security issue). Residents
> (sentinels and mail agents in particular) should have a secure way
> to identify themselves. (There's no reason for a resident to
> become a tourist and to move from one place to another; anyway, if
> an implementation allows the user to do this, it should take care
> of any security issue that may rise.)
>
> Tourists can be of any kind and freely move from one place to
> another (provided they get permission from the sentinels)
> traveling the IW. The implementation should provide a way for the
> user to create new tourists. Tourists can be cloned (with or
> without their baggage :). Also, the user has to have a simple way
> to instruct a tourist to do something (such as "Go on and search
> for this book!").
>
>  But why?
>
> Because it looks like a lot of fun. :-) And also because our brain
> is just a network of rather simple things... ;)
>
>
> Being visionary today, ;-)
>    Gabriele.
> --
> Gabriele Santilli <[EMAIL PROTECTED]> - Amigan - REBOL programmer
> Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif


-- 
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the 
subject, without the quotes.

Reply via email to