circle-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [circle] about separation between gui and core


From: thomasV
Subject: Re: [circle] about separation between gui and core
Date: Mon, 19 Jan 2004 14:15:04 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Thomas Mangin wrote:

Hello Thomas V,

And good year 2004. I am happy to see that some of you still have some time to hack on circle .. Thank you for founding this lstrip bug in magic.py .. As it seems that no one complained since the last version, I will assume that it mean that the code finally work and will fix my own version of the code. I will still accept bug report for this part of the code but my I am sorry to report that it is now some time that I do not have any time for non-work-related projects.

good year to you too.
sorry for answering so late...

your code does a great job, but there are
still a few files that it cannot correctly classify.
so, improvements are always welcome. :-)


I will give you my point of view, but feel free to do whatever you want with it as I will not have any time available to help anyone with some code anytime soon.

IMHO, circle primitive should be exported through a python module that any GUI (text, gtk, etc) can simply import. I can not see any reason for a socket. Having the code "available on request" is a bad idea as it mean that you still have the dependency within the circle core. I noticed that a python with threaded capacity is required to run circle, which make it impossible to use it even with the text interface under cygwin due to GTK.


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.

As you may know I looked at http://www.twisted-matrix.org/ when I wanted to help and split the core from the GUI. Twisted does have a *superb* (and I mean it) design and event handling. Should you may want to have a look to save lots of time. But this is not my call. You may want to know that I am using twisted at work and that my colleague and I are more than happy with it.

all right, see above

For the nameserver, I would take another approach as AFAIK the chat and nameserver are GUI independent. You only need to initialise the code when you need it. So the initialisation of the code could be done within the GUI but the module themselves could be in core.


what do you mean by "gui independent"?
for me they are gui dependent, in the sense that it does not
make sense to have them running if the gui is not running.

or maybe you mean "skin" by gui?

maybe I should explain more why I think the gui should be more than a skin.
I think the gui should include things like chat, gossip, etc.
That way, you could design a gui that does not do gossip,
if you are not interested into it (see my previous mail)


One big advantage is that it would make things much simpler for a host that runs both a client and a daemon. Currently, if you run a daemon and a client on the same machine,
two Nodes are running on it, and two File_servers.

This makes things messy, especially if they use the same shared directory,
because file_server gets confused by locked files. For example if you download, rename or move a file, the other fileserver will not know about it. So it would be
much better to have one single file_server.
Same for the node: it does not make sense to have two nodes running
on the same machine, except if they belong to two different users.
So that is why I would like the core to be very much like a daemon.
Finally, another advantage is that people would have a stronger
incentive to leave a daemon running on their machine.


Thomas







reply via email to

[Prev in Thread] Current Thread [Next in Thread]