So the concept, which after several attempts is proving harder to explain in prose than I had imagined it would be, is essentially writing your GUIs in HTML/JS and wrapping your code (virtually any perl code) in a mini web server to communicate with it through your browser. With this approach you instantly have a 100% cross-platform, GUI app. As long as the user has a browser (that's compatible with whatever JS you need to use) they can get the GUI for your program. The possibilities are endless, it strikes me that this is probably a good approach for writing GUIs for code running on "embedded devices" as well.
The module I've written to encapsulate the heavy lifting of an approach like this I'm tentatively calling ServerApp (though, other suggestions are welcome) - it's posted in the code section, there's also a (primitive) testing suite that I have not posted... However, my first program using this as a foundation can be used as a font previewer, it wants for more features, but is cool as-is: FontPreview
I'm posting this to initiate a discussion on several things relating to this concept:
Generally:
- is this a good idea?
- has this been done before?
- how can this be made more secure?
Specifically:
- I'm not a CPAN author (yet?), if this concept proves useful I would encourage people to assist me in bringing it to the repository
- Queries (GET/POSTs) to the ServerApp need to spawn new threads so that it can respond to several simultaneously should that need occur. I think there should also be an option to call your ServerApp->run_with() method asynchronously. I want to ensure that this is done correctly and portably (as one of the goals of the project is providing easy cross-platform GUI development), can I request some expertise in this area? (spawing threads/forking portably, etc)
There are certainly some limitations for this type of application, it needs to be web-like (e.g., pretty difficult to write a drawing app). The recent talk about AJAX (as exemplifed by gmail and google maps) certainly make this approach more like a desktop application.
Futhermore, the GUI framework in Firefox is another nice approach (XUL and javascript), not just for firefox extensions but as a general GUI framework.
The missing piece is a nice API to handle all this, and maybe a framework. Oh, then some XSLT to transform XUL <=> XAML. ;^)
It also likely requires a well formed MVC architecture for the application.
BTW: There was an attempt to provide a pTk style mapping for XUL, but it seems to have "withered on the vine".
Some resources:
- XUL::Node
- XULPlanet
- XAML (thats just the top link on Google, not an official MSFT link)
- Venkman (a Javascript IDE written entirely in JS and XUL)
- Helene (a nice IDE-style text edittor written in JS)
- Drawing with JS
I'd love to be able to apply all of that, but the lack of a single coherent API to support it makes it a bit difficult (tho XUL::Node might be a start). As to how a server app should behave, I suspect that trying to route everything thru the usual Apache/mod_perl channel might be difficult; you may want to consider HTTP::Daemon. As to threading/forking, I'll offer Thread::Apartment as a possible (albeit immature) solution.
right - embedded server, ServerApp.pm has a "use HTTP::Daemon" as it's 3rd or 4th line
- Your users will only use IE on Win32
- Your users will install ActivePerl
As for security ... what avenues of attack do you foresee? The big question is "Do you have anything going over a wire?" If you don't (and loopback doesn't count), then you don't need https, which is good because it's a pain in the ass to implement and/or deploy. (There's a reason why Apache uses OpenSSL instead of writing its own.)
As for using the browser as your GUI ... I wouldn't. Browsers right now suck ass as GUI environments. The only benefit they have is that a monkey can do something that looks okay. To get anything seriously good, you have to move out of the browser and into a real GUI environment like wxPerl or Tk. To me, the measure of a GUI environment is "Can you implement FreeCiv?" If you can't, then you're not a real GUI environment. Browsers are coming close, but they're not there yet.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
The good part is that it is easy to integrate your application with other web content. It helps to have an application that naturally integrates with a web site that your users already really like.
The bad part is that it is hard to make a really slick GUI without using a lot of browser-specific code. Recent javascript library development (AJAX) should make it easier to support IE and Mozilla. This hasn't done me any good so far, since my apps still support Netscape 4.72 on HP-UX.
It can be difficult to get users to install client software. If feasible, I usually favor a conventional web application.
So I suppose I should chime in since my one huge Perl project at the moment is a desktop app that works precisely this way. I got my inspiration for it from the node GUI with HTTP::Daemon and I have to say that while I was poking at it the one thing that struck me was, wouldn't it be good if there were an API for this. Tomorrow when I get in I will see how well this API matches my program structure and hopefully that will give me the basis for a more useful reply.
Regarding threads, I've played with threads once or twice during the lifetime of this particular project, and so far the benefit isn't really hitting me. The only clean way I can think of to use threads is to simply start off by spawning two threads, one to handle the HTTP::Daemon loop and one to do any work not directly related to generating the response. I don't think spawning a thread for each request will be good because it's too much overhead.
In terms of security, the most important thing is that you listen only on localhost, which you're already doing. You could also try generating a magic key to go into the query string like Google Desktop does, but I have not yet figured out what the security benefit of that is.
And don't forget, this may be cross-platform but an application developer still has to deal with the issue of users actually having Perl. For applications, you might want to use PAR to package executables for the platforms the app needs to run on.
It's sort of an open secret that your 'different approach' is variously frowned upon by various interests for various reasons. It's not to say its a bad idea. Even the old test of "can I write a drawing application in it" is becoming more and more feasible with what we commonly call a 'web browser' ... The real question is whether it will catch on and outshine the wxWidgets and DotNets of the world, until the next "paradigm shift" in GUI programming comes along.
see also: Bindows and API War (search for "HTAs and DHTML") for some additional perspectives.
Another option is just to drop the browser all together, and make your gui server just send control signals and data to pure Perl GUis directly through sockets.
That is already the easiest thing to do. Just have your users download the special client programs, and let them connect. Why have the overhead of the browser at all?
I'm not really a human, but I play one on earth. flash japh
Why have the overhead of the browser at all?
Because everyone pretty much already has a browser installed on their desktop, and they're already familiar w/ navigating inside the browser. And, at least for Firefox (and maybe Opera), the browsers have already solved much of the platform/OS compatibility issues.
GUI tookits, OTOH, - and esp, in my experience, Perl GUI toolkits - tend to have mixed success addressing the platform independence requirement.
I think some of your assumptions wrt browser capabilities may be a bit dated; XUL brings much functionality to the Firefox browser, and when XAML becomes "official" in '06(?), it will likely further change user expectations wrt browser capabilities.
Hence, the need for "plugins" may go away, and by writing MVC structured apps - w/ very loose coupling between the M and the V -, GUI apps become small local web servers, at the same time providing the option for remote execution for apps that need it. Whether the user needs a Perl - or Java or Python or C# or etc. - installation on their desktop will depend entirely on the complexity of the app, and the speed of their 'net connection (tho the security issues remain problematic).
So, wrt the OP, it would be nice to have a decent Perl API in development now to address the likely future transition to browser based GUIs, even if the widget set were limited to XUL/Firefox for the time being.