I agree that we should use the already existing si_* commands instead of duplicating any code. If there is anything we need in the GUI that is not yet available over si_* commands, then we should add it there first and then use it in the web interface. Ideally there should only be presentation code in the web pages.
The problem with AJAX is that you still need server side code to get the data you need and to actually invoke the requested commands. AJAX libraries can help you by automatically calling the right methods on the server side and returning the results in a format that you can easily process in Javascript. I do know the theory behind AJAX, but before this I had never written an AJAX interface either. It is more work than the traditional server based processing, but I think that a good AJAX library could help to make this a little easier. If we put all presentation code in JavaScript, we only need a very thin layer of actual server code that calls the si_* commands and formats the output for the Javascript code. The question is what language we should use for the server side code, there are a few options that come to my mind: - Mono/ASP.NET: I would probably use that if I wrote the interface purely for myself, because I'm a .NET developer on my day to day job. However I cannot really recommend that for SI in general, because you would have the huge Mono dependency and afaik it hasn't a good reputation in the foss world, because of patent fears, etc. - PHP: The big advantage is that it is used in so many web sites and is already installed on many servers. However the language itself is optimized for server side generation of HTML. - Ruby on Rails: I haven't done anything in Ruby myself, but it is gaining huge popularity. The language itself is very expressive and similar to python. And the web framework Ruby on Rails is well suited for AJAX development. The biggest disadvantage that I am aware of is, that the language is not completely "finalized" and from time to time there are some changes that are not backward compatible and break some things. The nice thing about Ruby on Rails is that the separation of Model (si_*), View (JS) and Controller (Ruby) is at its heart, which could make things a little bit more easier than in other languages. I'll have to look at it a little more closely and try it out though, before I know if this is the best choice for SI. Feel free to add your own suggestions to the list above. Thomas Krause -----Ursprüngliche Nachricht----- Von: Andrea Righi [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 23. April 2008 12:27 An: Thomas Krause Cc: [email protected] Betreff: Re: [sisuite-users] si monitoring webpage Thomas Krause wrote: > Andrea, > > I'm glad that you like it. The screenshots look OK to me. > > What I also need in the near future is a GUI frontend to si_mkclientnetboot > that lets me set up one or more clients for reimaging. > > Seeing this ticket: http://trac.systemimager.org/ticket/13 I can see that > you are also interested in making more SI features available through GUIs. > > Do you have concrete plans for this? Nothing concrete, except the few requirements defined in the ticket. I also started to write the GUI in python and PyGTK for its simplicity and the speed of development (in ~30mins I've implemented the start/stop/configuration of the daemons). Anyway this interface is not yet usable and needs additional work. At the moment the most important functionalities to be implemented with a GUI are: - monitoring (ok, and for this we already have good implementations) - an interface to si_clusterconfig (that also produces a XML output, see /etc/systemimager/cluster.xml) - an interface to start/stop/configure systemimager daemons (at least a simple interface to just edit /etc/systemimager/* files and start/stop /etc/init.d/systemimager* daemons) - an inteface to manage images (copy, rename, remove, show details) - an interface to manage clients boot (si_mkclientnetboot, DHCP configuration, etc) > I believe that a web interface is the best way to do this administration. I agree, I've to say that a full AJAX interface would be a lot more appealing than the usual script/binary GUI and I think this is the right direction. > I could develop such an interface (at least to si_mkclientnetboot), > but I'd > like to know if you have any requirements or ideas how such an interface > should look like. IMHO it would be great if the web interface would be able to just execute si_mkclientnetboot (or any other SystemImager commands) for now. In this way we wouldn't have redundant code to be maintained/fixed. And since SI is fully implemented in perl it's not so easy to export API or interfaces to web-based applications now. So, the invocation of SI methods, at the moment, can only be performed directly by the execution of SI commands from the shell. Probably a RMI/RPC approach would be the best solution, but let's proceed step by step... > Another question is in what programming language this should be written in. > I'm not really comfortable with Perl and afaik it isn't that well suited for > webpages anyway. Anything else would probably add further dependencies to SI > though. As I said AJAX IMHO is the right direction. Unfortunately I'm not familiar with AJAX at all, so I don't know which AJAX framework should be used. Your si_monitor client seems fine, what are the limitations/advantages/disadvantages to implement all the GUI functionalities in the same way? -Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ sisuite-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-users
