Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Browsers as stand-alone UI

by dragonchild (Archbishop)
on Apr 07, 2004 at 17:23 UTC ( #343346=perlmeditation: print w/ replies, xml ) Need Help??

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?

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Comment on Browsers as stand-alone UI
Re: Browsers as stand-alone UI
by gjb (Vicar) on Apr 07, 2004 at 17:53 UTC

    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.

      ... 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?

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        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.

        ----
        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

Re: Browsers as stand-alone UI
by andreychek (Parson) on Apr 07, 2004 at 17:54 UTC

    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


    --
    Lucy: "What happens if you practice the piano for 20 years and then end up not being rich and famous?"
    Schroeder: "The joy is in the playing."

      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).

      ----
      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

Re: Browsers as stand-alone UI
by stvn (Monsignor) on Apr 07, 2004 at 18:07 UTC
    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
Re: Browsers as stand-alone UI
by halley (Prior) on Apr 07, 2004 at 18:10 UTC
    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.

    --
    [ e d @ h a l l e y . c c ]

      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 ...

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        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.

        --
        [ e d @ h a l l e y . c c ]

      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.
      my @a=qw(random brilliant braindead); print $a[rand(@a)];
Re: Browsers as stand-alone UI
by blue_cowdawg (Monsignor) on Apr 07, 2004 at 18:24 UTC

        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.

Re: Browsers as stand-alone UI
by flyingmoose (Priest) on Apr 07, 2004 at 21:30 UTC

    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 :)

      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.

      ----
      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

Re: Browsers as stand-alone UI
by bbfu (Curate) on Apr 08, 2004 at 01:44 UTC

    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.

    bbfu
    Black flowers blossom
    Fearless on my breath

Re: Browsers as stand-alone UI
by tilly (Archbishop) on Apr 08, 2004 at 04:38 UTC
    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.)

Re: Browsers as stand-alone UI
by eserte (Deacon) on Apr 08, 2004 at 08:57 UTC
    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.
For those of us who have never seen Quicken...
by jonadab (Parson) on Apr 08, 2004 at 10:42 UTC

    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.)


    ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
Re: Browsers as stand-alone UI
by zentara (Archbishop) on Apr 08, 2004 at 12:59 UTC
    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.

    I'm not really a human, but I play one on earth. flash japh
      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! :-)

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

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

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


        I'm not really a human, but I play one on earth. flash japh
Re: Browsers as stand-alone UI
by synistar (Pilgrim) on Apr 08, 2004 at 14:59 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://343346]
Approved by diotalevi
Front-paged by stvn
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (2)
As of 2014-09-20 19:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (160 votes), past polls