Re: [circle] about separation between gui and core

[Steven and Julie]

On Mon, 19 Jan 2004 14:15:04 +0100, 
thomasV <address@hidden> wrote:

> the reason why I would like to use a socket is that it would allow
> non-python applications to be written and interact with the core.
> I know that python is great, but after all it is primarily a script
> language, with not so good performance (compared to caml for example).
> 
> If the core is a different program than the gui, then people will be 
> able to write new, faster versions of the core (using twisted for
> example) without interfering with the rest of the program.
> 
> Also, using two programs would enforce a true separation between the
> two layers.

I seem to recall a little over two years ago or there abouts, sitting in a cafe 
with Paul, Nathan, Jiri, and someone else I can't remember.  Probably Ryan.

At that time, I suggested this very concept of using a socket to seperate the 
networking components from the UI.  Though my primary reasoning at the time was 
that I didn't want to learn Python (which is the main, if not the sole reason, 
why I've never looked into helping with the project -- I still have neither the 
time, nor sufficient reason to learn Python).  I also mentioned, along with the 
possibility of making the core multi-user (so each users UI connects to a 
single system-wide core), all the points you just raised here.

At the time, the response was something along the lines of "why would anyone 
want to do that?", followed by a, "we can't be bothered, you do it".  It's a 
shame really, because it probably would have made life easier to have done it 
at that somewhat earlier stage.

Floating around the back of my mind at the time was this; the rather 
interesting possibility of implementing file serving, gossip and chat as 
modules, each connecting to the core via its socket interface.  Each module 
would advertise both a command-based interface (which would be avaliable 
through virtually any UI), and a more direct interface (for those UI's that 
understand how to use it).  File transfers could even be supported by "pushing" 
the file from the daemon (once downloaded) into the users download directory, 
if the client UI isn't capable of recieving it by other means.

For instance, an advanced file transfer module might offer four methods of 
passing along a file that's in the process of being downloaded:
1) push method; as notied above, for clients that don't even have basic 
download capability.  They just request that the file be deposited in a 
specific directory (and optionally under a specific filename), when finished 
downloading.  This method would be shunned and considered evil, to be used only 
as a last resort; for instance it doesn't support non-local daemon's, which the 
latter methods would support quite trivially.  However, it would be usable by 
clients without any concept of file transfer at all.
2) by request; the daemon will hold the file, serving it up from start to 
finish at the direct request of the client UI (which would also specify the 
maximum size of each chunk as it asks for it).  A command-line client might do 
it this way, ignoring the intermediate peogress messages, and only notifying 
the user when the file's been downloaded, and is waiting to be picked up.  It 
would then fetch the entire file from the daemon in a single chunk, at the 
users request.
3) progressive; much like "by request" above, but the file chunks would be 
automatically included along with the progress notification messages, as long 
as they followed on directly after the previous one (ala TCP de-fragmentation). 
 This would be useful for a not-so-intelligent UI that doesn't want to fuss 
around with reassembly of a fragmented file, like when an audio file is being 
played right off the net (the client need be little more than a fifo buffer to 
the audio drivers).
4) as it comes; simply pass each chunk of the file along with its progress 
notification message (and associated offset, which would probably be included 
anyhow, in methods 2 and 3 also), as it gets recieved.  This would be the usual 
for most GUI's which would simply write it to disk preceeded by a file seek to 
the appropriate location.

I'm not sure how you'd handle the case of multiple client UI's each wanting to 
interract with the same modules.  I suppose if one UI started downloading a 
file, it would then "own" that file.  Other UI's of that user might however be 
able to observe the download, and may even be able to take it over should the 
originating UI get closed.  This would make it possible to have a Circle UI, a 
Circle panel applet, and a web browser, all downloading files at the same time, 
and all downloads showing up in each others file transfer lists.  (Recieving 
other clients progress messages would be optional)

Even more interesting, would be a modular multi-user core.  For instance, if a 
client requests a certain file which is already being downloaded by another, it 
would be trivial to split the feed to both clients, and either fetch the first 
part from the original client (assuming said client isn't able to modify the 
file contents in the meantime), or re-fetch the already-processed portion from 
the source(s).  An example of the former, would be having the daemon download 
into a temporary file (set to allow read-only access), and allowing the client 
to hardlink to it (or softlink if neccesary) until it's completed.  The client 
could then either make a copy before it was deleted (if it was softlinked), or 
have the daemon re-own and delete its link (if it was hardlinked and the client 
UI was the sole requestor).


No, I didn't remember all that, I remember the discussion, following which I'd 
written those few ideas (rather cryptically) in a file which I still happen to 
have.  At the time I was going to write it out a little better and stick it 
into the gossip, until I realised I was getting a little sidetracked and had 
other work I needed to get on with.  Anyhow, maybe this little trip into 
imagination will add inspiration to the concept of sepparation with a socket.  
;)


Zaphod