[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [circle] about separation between gui and core
From: |
Steven and Julie |
Subject: |
Re: [circle] about separation between gui and core |
Date: |
Tue, 20 Jan 2004 03:37:13 +1000 |
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