Re: [circle] circle's old daemons : an essay on the separation between the gui and core....

[Thomas Voegtlin]

Steven and Julie wrote:

> Is there a good document on "Circle-internals" anywhere, that doesn't
> require digging through Python code?
hum... I do not think so.
there is a set of slides by Paul on the webpage.
and of course, we ought to write better documented code.

> I'm wondering...
>
> 1. Does Circle establish direct connections with people you're talking to?
> ie. if five Circle clients on a given machine are all talking to the same
> person, would that make for five individual outgoing connections?  Likewise
> for its miscelaneous peer connections.  Does each one establish its own set
> of connections to the network?
5 clients on the same machine would use five different port numbers.
so that would make 5 different connections.

Likewise, each client would have its own set of peers.
Clients running on the same machine may be peers of eachother.

> 2. Are channel messages multi-targeted, or sent individually to each
> participant?
sent individually.
when you post to a channel, circle first asks the hashtable about the list
of participants to this channel, and then it sends individually to each 
of them.
So it is possible to use the daemon for asking the hashtable.

Note that this makes it possible to use a java applet for chat, if we 
are to use
a web browser as a gui. [however, I'm not gonna write it because I hate 
java].

> 3. What non-user traffic (ie. traffic not directly caused by the user doing
> something with their client) is there for each client, in terms of logon,
> pre-hashtable participation, and post-hashtable participation, and how much
> of that would be made redundant if CircleD took over as sole network
> connection for the site.
good question... deserves to be investigated.

> 4. Is the offline message handling a special case, or a regular message that
> hasn't been "recieved" yet?
I'm not sure to understand your question... offline messages are stored 
in a "cache",
so you retrieve them when you next logon. So yes, they are treated as a 
special case.
(they do not wander indefinitely through the network, desperately 
looking for a recipient)

> 5. What happens when there is, say, seven Circle clients on a single
> machine, all talking to each other both in channels and privately.  Do they
> start making connections to each other, or do they nominate a client to
> which they all connect?
see above. they use the hashtable for channels, and for /find.

> The point being if Circle's logged into a CircleD using a thin version of
> the protocol, and left CircleD to carry the network, distributing chat,
> gossip, etc. back to the appropriate Circle clients, it would not only make
> implementing new interfaces a whole lot easier, but also make far better use
> of resources by sharing connections, and allowing more intelligent
> management of things.
>
> Plus, making CircleD more along the lines of a system service, would allow
> sysadmins to shield the Circle network from users who think they know Unix
> but wouldn't know how to run the Red Hat installer, and has just attended
> their third week of Java/C/Python/Lisp/ML/Snobol classes.  Furthermore,
> CircleD could handle filtering out any evil traffic flowing in either
> direction, so the Circle clients can get down to the job of interracting
> with the user.
>
> Anyhow...
>  
yes, there probably would be benefits in doing that...
however it would also enpower the sysadmin, I guess.


Thomas




> From: "Thomas Voegtlin" <address@hidden>
>
>  
>
> > So here is my proposal, if we want to separate gui and core of circle:
> >
> > We could use circled and use the 'get' and 'search' commands I added to
> >    
> it.
>
> Isn't there already a circle-get command?  A dedicated thin client which
> takes a file op request as commandline arguments, and persisits just until
> it completes, would do just fine here.  Output of such a command should be
> tailored in one of a few ways.
>
> Normal: Tells the user that it's connecting to the circle daemon, requesting
> for the file, and then gives a download progress indicator.  For a search,
> it would show its results instead of the progress indicator.
>
> Quiet: Says nothing except "Done" for downloads, or the actual results for a
> search, plus any errors encountered.
>
> Very Quiet: Says nothing at all, accept errors (to stderr). Not much use
> with a search request, but fine for backgrounded downloads when you don't
> want it interrupting your vi session.
>
> Debug: spews forth all sorts of crap the average user really doesn't want to
> see.  But who knows, someone might.
>
> Programmed: Angled towards machine parsability rather than human use, quite
> verbose, with progress indicator by means of simply writing out the amount
> recieved so far at the end of each block.  Further, provide an optional
> argument specifying either a filename to place the recieved data into (the
> actual real name would be included in the stuff written out as it prepares
> to recieve the file), or a filedes provided by the caller into which the
> downloaded file should be written (a pipe attached to an ogg player, for
> instance).
>
> File ops don't have a lot of persistance, and are essentially anonymous.
> You send your request, get your responce, and it's done.  There's generally
> little point issuing a responce unless you're willing to wait for it, so a
> CGI interface can build the page as it gets its responces, and then forget
> about the whole thing when it's done and get on with the next user.
>
>
>  
>
> > For chat, the gui would ask to the daemon the list of people on a channel.
> > However, I think it should bypass the daemon for sending messages, once
> > it knows the list of recipients.
> >    
>
> I disagree here.  Using CircleD as a connection proxy allows the clients to
> have a simpler and much safer interface.  Unlike connections to other people
> around the world, the clients themselves can have a connection which is as
> garanteed to be safe and clean.  (Well, as much as their sysadmin is
> reliable.  And if he's not, then it's not going to matter a whole lot
> anyhow)
>
> This allows the clients to be made very thin without compromising network
> reliability.  Furthermore, I expect there are certain costs involved in
> setting up and maintaining a user connection, some of which can be handed
> off to the daemon.  Plus, for anal sysadmins who don't trust their users, it
> allows them to further shield Circle's innards from their users storing
> network/daemon configuration and even the users hidden identity out of their
> reach.
>
> If you're going to go to the effort of seperating the network code from the
> client, making the connection between them as thin as possible (though not
> to the point of reducing functionality) can only be a bonus.  This also
> makes life easier for a non-continuous client such as a CGI script.
>
>
>  
>
> > the advantage of using circled is that it is possible to achieve
> >    
> separation
>  
>
> > progressively, which should be much easier than to rewrite everything
> > from scratch.
> >    
>
> True.  Question is where you intend the seperation to be.  What you're
> suggesting, isn't true seperation of network from client, it's seperation of
> administration from client.  Both client and daemon still need to be able to
> interract directly with the network, which seems to be to be a fairly
> expensive capability.
>
>
> Steven (aka Zaphod)
>
>
>
> _______________________________________________
> Circle-discuss mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/circle-discuss
>
>
>