David,
I've started the prototype, which of course generated more questions
than code. It is available at http://www.areeda.com/jclientgui.jar.
Download and run java -jar clientgui.jar. All it does is the display
portion of the Tasks tab, but it does demonstrate a polling RPC task and
GUI. I have tested it connecting to localhost on Linux (Ubuntu and
CentOs) systems. It requires Java 1.6 (6) and I think it works with
Java 7 but haven't done that testing yet. it requires the client run an
rpc server on port 31416.
Here's my first round of questions:
* I'm using the RPC call: <get_results>false</get_results>. I'm
impressed by the RPC protocol, it's the easiest one I've worked
with. Is there documentation on the requests available, calling
arguments and returned information? Getting that stuff from the
code is ..uh.. tedious. If not, can I start the Wiki page?
* The Status codes in the .h file don't seem to match the manager
display. My running processes return status = 2, which I /think/
translates to Exiting rather than Executing. Am I looking in the
wrong place? Downloaded, uploaded and other codes seem reasonable.
* Windows doesn't seem to open the same port (31416). is this
something I'm doing wrong? How do Macs handle RPC?
* Is there some license verbiage I should put into each source file.
Where to go from here?
* I use a paradigm called rapid prototyping and step-wise
refinement. I think kids call it Extreme Programming but I'm not
sure what that really is. Anyway, I have a lot of documentation,
refactoring and refining to do on what I have, so no hurry getting
back to me.
* I'd like to get all my remote computers managed by one manager. I
have a couple of *nix system on both the local (secure) network
and Internet.
o Is there a way to select a particular interface with
--allow_remote_gui_rpc or is should security be done with
firewalls and --check_all_logins?
o What user/password get used by --check_all_logins?
o Do you envision the hierarchy as Computer->Project->Task or
Project->Computer->Task
* I'll be implementing preferences soon. Client control will be last.
o Any idea what will be in the XML configuration. I assume we
want it to be an external file editable by hand, if necessary.
o I'm thinking skins would be better implemented as xml than
css because of Java options not in css such as Swing Look
and Feel. I can parse a css for a lot of the usual stuff
(font, style, background, ...)
o I'm thinking more of the values passed in the result and the
state query are interesting. I want to use preferences to
decide what gets displayed. Is there anything in there that
shouldn't be displayed?
I'm about half way through my notes but some guidance on this stuff will
keep me busy for a while.
Joe
On 04/19/2011 10:41 AM, David Anderson wrote:
> Joe:
>
> I think Java would be viable.
> I'd recommend implementing a simple prototype -
> maybe like the Tasks tab in the current manager -
> and then see how it looks on the different platforms.
>
> Let me know if you need any guidance in this.
>
> -- David
>
> On 19-Apr-2011 10:11 AM, Joe Areeda wrote:
>> I was looking at the help wanted-programming section.
>>
>> The project that really caught my eye is:
>>> * Reimplement the BOINC Manager so that it is:
>>> o Configurable via an XML file
>>> o Skinnable via CSS
>>> o nicer-looking than the WxWidgets? version
>>>
>> I know it's a biggie, but I have the time and it doesn't seem like an
>> urgent need.
>>
>> Before I dig in, understand what that really means, and produce a
>> proposal I have a question.
>>
>> Would there be major objections to implementing it in Java? Since the
>> manager communicates with clients on multiple machines I assume it's all
>> done through RPCs.
>>
>> I've had much better results with cross platform GUI applications in
>> Java than in C++. I can test in a few versions of Windows and a few in
>> *nix. I don't have any Macs available but have produced java apps that
>> work on all 3.
>>
>> Joe
>>
>> _______________________________________________
>> boinc_dev mailing list
>> [email protected]
>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>> To unsubscribe, visit the above URL and
>> (near bottom of page) enter your email address.
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
