Browsers as stand-alone UI

[dragonchild]

This is a question and a meditation.

I've been working on a very light-weight replacement for Quicken (which sucks rocks) and, obviously, Perl CGI is the way to go. There's modules that parse QIF's, DBD::SQLite is a great mini-datastore, and HTML is the easiest way to make things happen. But, I don't want to set up a webserver just to do my books. And, since I'm going to be running this on Win32, cygwin is annoying to work with as a production environment, even for small apps.

So, I was wondering if this is possible:

1. You open a file on your machine.
2. IE looks at the file and executes it
3. That file returns back some HTML, which IE displays.
4. All the links go back to that file, causing step #2 to reoccur.

That's the question. The meditation is this - if this were possible, what does that open up in terms of distributability of apps, especially on Win32. IE is an excellent UI, the known HTML limitations aside. You are more easily able to maintain state (because you're guaranteed you only have one user). Anyone ever do anything remotely similar to this?

[andreychek]

What you're doing made me think of some solutions I'm currently working on. OpenThought is designed to provide a better application interface than the general clunkiness available on the web. It does so by not requiring you to reload the page every time you click a link, through the use of a hidden frame. So, you can dynamically update portions of the screen

It's built on top of OpenPlugin, which, amongst other things, abstracts the browser request cycle. That is, it has plugins with drivers that provide an abstration layer on top of CGI and mod_perl. It's fairly simple to add new drivers.

I thought it would be pretty neat to run an OpenThought application on my PDA, but I have no interest in running CGI or mod_perl on my little Zaurus. So I'm looking to write a driver that includes it's own skeleton web server (in Perl of course), something just enough to handle receiving headers and parameters, and returning content.

With something like that, I could put an app on my company web server using the mod_perl driver, or I could move the same app to my PDA, simply by changing the driver being used. No code changes required here :-)

Of course, I haven't written that driver yet...:-)

(shameless plug) Anyone who thinks this is a neat idea can find some cool development snapshots on OpenThought.net, or, better yet, message me and I'll give you some even newer stuff (with lots of new and useful goodies :-)

Anyhow, this is an interesting question, I'm curious what other sorts of solutions folks have come up with.

-Eric

[hardburn]

So I'm looking to write a driver that includes it's own skeleton web server (in Perl of course), something just enough to handle receiving headers and parameters, and returning content.

This shouldn't be hard at all, and a lot of the work is already done for you. I wouldn't have it do CGI, but rather model it like mod_perl RequestHandlers (call a method in a Perl package with an object that contains information about the request).

[gjb]

At some point you could use ActiveState Perl as a scripting host under Win2K and have Perl scipts executed by IE. At the time I tried it, it worked and I turned it off since I considered it a bit too powerful. I'd guess it's still possible although I haven't used ActiveState in quite a while.

The alternative is JavaScript ;)

Hope this helps, -gjb-

Update: the security depends on that of Microsoft's Scripting Host and given that company's track record I decided to take no chances.

I just checked ActiveState's website: the thing to look for is PerlScript. I'll give it a try later when I can reboot after installing ActiveState Perl.

[dragonchild]

... I considered it a bit too powerful.

I'm curious - what did you consider it too powerful for? That's an odd sentiment to have, IMHO.

Also, would this same trick work under WinXP?

[hardburn]

what did you consider it too powerful for?

I'd personally consider it a security risk. Safe.pm not withstanding, Perl doesn't have a lot of sandboxing features that are typical of browser-based langauges.

Also, would this same trick work under WinXP?

It should.

[halley]

Just embed a "web" service into your Perl application. Have it open on a custom port. Run the browser to point at that custom port. http://localhost:3456/ This is how many applications offer web-browser front ends, including Slim Device's SLIMP3 server (in Perl!), the CUPS printer configuration service, and several others.

[dragonchild]

This may be an unreasonable design goal, but I wanted to have the end result meet the following requirements:
1. The setup work required to install this application would ideally be "Copy stuff to this location and make a link on the Desktop"
2. Launching this application would be nothing more than clicking on the link which would bring up IE.
3. No (additional) security holes would be created by this app.
4. Preferably, no security holes would be used benignly by this app.

I suppose that #2 could be handle by a WinSript that would launch the server, then launch a webbrowser with the appropriate link ...

[halley]

Nothing wrong with your requirements, and nothing that is incompatible with "run your own web service."
1. Copy perl scripts and data files to this location, and make a link on the desktop that launches the main perl script. The main script can adjust @INC to use its own private stash of modules.
2. A perl script can bring up the user's IE with a simple statement: system("start/b  http://localhost:2345/").
3. If your web service only accepts connections originating from localhost, it's not going to open up problems on the LAN or internet.
4. I haven't suggested you exploit any vulnerability to implement this.

It would be harder to decide when to stop, since the user's free to wander off and browse other pages, or close the IE session.

Update: Look into HTTP::Daemon for a start, but that's only one option. I'm sure there's others.

[Rhandom]

This is exactly what I did for a membership survey/directory program for a local church congregation. The computer was a Windows XP box with no network connection or anything. But I made a module with its own basic server. Then I ran requests from localhost. At the time I used Active State to do things. Now- I'd skip that step and just use a PAR executable. Copy one file. Click on it and your off. If you can get fork to work on XP you could fork and exec an IE window. Nice and easy.

[blue_cowdawg]

I've been working on a very light-weight replacement for Quicken (which sucks rocks) and, obviously, Perl CGI is the way to go.

I'll take a chance of being accused of heresy here and say that I am not convinced that is 100% true. It is one way of doing this but not necessarily the way to go.

Ever since my flight from The Evil Empire and my reliance on Open Source software for my personal and professional desktop and laptop needs and quite a majority of server needs I haven't looked at or worked with Quicken®. I did use Quicken® when I was using the appropriate excuse for an OS that it ran on. It suited my needs at that time. I have worked with GnuCash and found that for my modest needs it works fine.

I say all that to say this: I refuse to reinvent the wheel. There are products out there that work and before I am going to rewrite one of them I first must answer the question: "What do I have to gain by expending my energy on that?"

So, I was wondering if this is possible:
1. You open a file on your machine.
2. IE looks at the file and executes it
3. That file returns back some HTML, which IE displays.
4. All the links go back to that file, causing step #2 to reoccur.

Yep, it's possible. Isn't that what an ActiveX® object does? I hated the darn things when I had to deal with them. Just as a "proof of concept" when ActiveX® was new and shiny I wrote an ActiveX® of a very malicous nature. It stole the contents of a Microsoft Wallet and wrote the contents to a MSSQL database for my later perusal. I wrote it and had a friend and coworker of mine execute it from my internal website at work just to prove a point. I later destroyed the code. Point being I don't like having browsers execute things on my machine other than trivial JavaScript stuff.

That's the question. The meditation is this - if this were possible, what does that open up in terms of distributability of apps, especially on Win32. IE is an excellent UI, the known HTML limitations aside.

I can see using IE (or other embedded browsers) as your presentation layer but not your execution layer. Let your backend code do the execution and let the browser do what it was designed for and present.

As far as software distribution, portability and such there is more than legions of facets to that topic, more than I am abitious enough to get into here.

I'll say this though: the "promise" of Java was supposed to be that whole "write once run anywhere" thing that Scott MacNeally was touting for so long. What Java was supposed to deliver was a development environment were your application was embedded within the browser and could run on any browser without a plugin. Albeit you could argue that a JVM is still a plug-in. Lots of folks have written lots of apps in Java using the insert browser here browser as the presentation layer. Very few of them that I've seen have impressed me in terms of performance or even portability. Case in point are some applications that my company has developed for internal use that will not run on Netscape but will on IE or vice versa. That isn't portability or "write once run anywhere" in my book.

OBTW: I agree with your assesment of Cygwin. I am done with Cygwin.

[stvn]

dragonchild

One (possible) solution is to use HTML Applications. They are essentially just a local instance of IE without some of the browser chrome and security restrictions that "online" IE has.

Now I haven't used these in a while, and it looks to me that MS is not really that exited about them anymore, so you may hit some barriers that have sprung up since I last used them (back in 2001-2002). I used them with javascript myself (because at the time i was more my language of choice), and was able to do a number of things like read and write text and XML files as well as access an Access DB through ADO. As for using them with perl, i would expect that you can install ActiveState perl as an Active Scripting/Windows Script Host language and use it in HTAs the same way you would use it in ASP pages (although I have never tried this myself, so I may be totally wrong).

If this does not work, there is always Personal Web Server, which is really just IIS with its shoelaces tied together. You would be limited to just plain vanilla CGI most likely (I dont know if you care about that). In my (somewhat limited) experience with it, it was not that much of a resource hog.

-stvn

[flyingmoose]

If you don't want to heavy a webserver, perhaps you could be like webmin and run a baby perl webserver inside your app? Then it would also work for all browsers and not just IE. Webmin does SSL, and you can also do neat things like only accepting connections over the local host. Yes, I just mentioned a Linux app -- I know -- but it's Perl, and it is an example of a baby web server.

Not to be misinterpreted, but what your are proposing is not only IE centric but rather hackish and non-standard. If it happens to work, it may not work in the future with different versions of IE -- and it's just weird. I would install a baby pure-perl deamon as a service -- and code your app so it works with all browsers, not just IE. And you can also use SQL, etc -- it's CGI, that's a well (or at least better) defined idiom for writing software.

Update -- some other monks have suggested the micro-server and localhost, good for them. I want to add, dragon', that security holes are invented by programmers, not network sockets or the programmers who use them. Write solid code, and code it wisely, and your system will remain safe. If this means localhost only, that's the way to go. For network apps, Perl is not a security hole either -- it's bad usage of Perl. However, as a converse, I would stipulate that IIS is a security hole, rather than bad usage of IIS :)

[hardburn]

I want to add, dragon', that security holes are invented by programmers, not network sockets or the programmers who use them.

If you're talking about the Windows Scripting Host solution offered above, then realize that WSH is probably a bigger security hole than IIS is. It doesn't matter if it's hosting Perl or VB code. The poor seperation of user privileges that is common in Win32 environments means that just having it on is a problem.

This is a highly unfortunate situation. The WinNT permission model is far superior to the classical Unix model, but applications and sysadmins don't make good use of it. Many, perhaps most, security problems on Win32 would go away if its access controls were used fully.

[synistar]

My first instinct at seeing your message was to point you at SQL-Ledger, which is written in perl as a web application. It is designed to be more of general accounting package but undoubtedly has a lot of what you are looking for already built.

But after rereading your message I think you should look at using the Mozilla platform. There is a slowly growing group of people using Mozilla for application interfaces (even the US Navy). Combining it with a small lightweight httpd (e.g. tinyweb, Jetty (300K java httpd )would probably work (Updated: added webserver links). Here are some articles about it if you wish to pursue this course:

• Remote Application Development with Mozilla
• Remote Application Development with Mozilla, Part 2
• Creating Applications with Mozilla - Book
• Example of SVG app (Tetris)

[eserte]

I do the following with bbbike: a script is starting a small web server (tinyhttpd, but you can also choose thttpd or HTTP::Daemon) on a custom port. This web server should be capable of handling cgi scripts or executing perl code directly. Then delay the execution a little bit to get the web server settled, and finally fire the web browser pointed to the cgi script on the web server. You could even put perl, the web server and your application on a CD ROM and start it directly without the requirement of an installation.

[bbfu]

It seems to me that AWTDI might be to use named pipes, though I'm not sure how well supported they are with perl on Win32. But, in theory, you could just leave your application running in the background (or a small program that would launch your program upon demand), and point the browser to the named pipe and have it treat it like a normal file. Of course, this makes passing parameters to the file difficult, so maybe it wouldn't work out after all.

[tilly]

I've not seen support for this in IE.

However if you're planning to use so many open source pieces, why not use one more and make the whole thing browser-independent? If Mozilla doesn't have support for essentially running a local CGI, you could try to add it. Alternately you could build an interface with XUL. There are (dunno how ready for use, but the start is there) Perl bindings at http://plxpcom.mozdev.org/. That might let you do pretty much what you planned to do, with more power, in a more cross-platform way.

(Or it might not work so well. This is a stack of technologies that I've heard of, not worked with.)

[jonadab]

I'm mostly just curious, but what does Quicken (or your replacement) do that can't be easily duplicated with a spreadsheet (say, OpenOffice.org Calc)? Is it just that a spreadsheet UI is too complex for some of your users, or is there some bit of functionality missing?

I ask because it's been my habbit to use a spreadsheet to handle anything related to finances, which seems to be Quicken's problem space from what I know of it (which, admittedly, is little), and I'm wondering whether my approach is placing limitations on me. (If it's only a question of the spreadsheet UI being complex, then I won't worry about that, since for me that's a non-issue; but I'm wondering if there is something else I'm missing.)

[zentara]

It seems like you are going thru alot of trouble just so you can use CGI. If you don't want to do this over a network, why use CGI. Tk could do this quite easily. There are quite a few modules available, like Tk::TableMatrix. It's xs code and is pretty fast.

[dragonchild]

Because this is a personal project for which I have zero time. I don't want to spend a most of it fooling with the user interface when I know HTML nearly inside and out. Also, the web browser is rapidly becoming the standard UI for the majority of people. Don't fight the Man, man! :-)

[zentara]

Don't fight the Man, man! :-)

I have my hands full just fighting the WOMEN. :-)