[Top][All Lists]

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

Re: [GNUnet-developers] OS-independent GUI, poor client-server messages

From: hwkks
Subject: Re: [GNUnet-developers] OS-independent GUI, poor client-server messages
Date: Tue, 24 Aug 2004 13:03:54 +0200
User-agent: Mozilla Thunderbird 0.6 (Windows/20040502)

Christian Grothoff wrote:

On Tuesday 24 Aug 2004 2:39 am, hwkks wrote:
Hi list,
I just thought about writing an OS-independent GUI in Java (yes, I know,
Java sucks), but then I saw that the client-server messages are very poor.


There seems to be no way to search, to download or to view current
downloads. Are you planning to implement this soon?

Well, how do you think the current clients work? :-). As Nils already said, you missed half the message definitions. Anyway, you may not want to deal with this low-level messaging anyway. The GNUnet client (and in particular the libesed2 library) have to do a lot more than just issue a single 'search' or 'download' query. But as Nils also mentioned, there is freeway. Freeway (re)implements (most of) libesed2 in Java, from message handling to the GUI. I would suggest that you look into the freeway code.

Ok, sorry, I see I was too fast. I thought it would be like mldonkey and sancho(a GUI). The core does all the work and the GUI is only for viewing and simple operating. I should have read the docu more carefully, sorry about that. But what I really wanted to build is a GUI like Sancho. If I understand it right the client has to run as long as you download a file. In a case where the core runs on a router without a display and the client works on another PC this would not be optimal. In this case it would be better if the core and client work on the router while I interact with the client from a GUI on my win32 system. So I can close the GUI and shutdown my system while gnunet still downloads my files on the router.
But I guess you don't plan to implement this into the client, or?


reply via email to

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