Slashdot Mirror
Mozilla.org Releases Protozilla
An anonymous reader wrote in to tell us about Protozilla's release. "Protozilla enables Mozilla to execute any CGI program on the local disk directly, without passing it through an HTTP server." Its a strange little idea that could definitely simplify development.
err, When can we expect this as a mature product? Why will I want to use it??
I am puzzled, aren't the developers aware that there are slightly more pressing matters to tie up than think up "tricks". I do not want to be appear harsh but I have come to think of this mozilla group as being a bunch of developers who imagine membership of the club is an end in itself. The only products released or discussed are tools to enable rapid development. Something they seem singularly unable of doing themselves. (gulp, I suspect I may be bitten for these thoughts)
Actually it's exactly the opposite: It's moving back towards lots of small tools which do one job well. This is about allowing new protocols to be implemented as small external applications, rather than throwing everything into the Mozilla code.
Good isn't it. Just as virtually every other app on the Linux desktop is converging onto either the KDE or GNOME widget sets, Mozilla intoduces a new proprietary way to do things, totally seperate to anything else.
Now that's what I call forward thinking (NOT).
Hopefully Konqueror will continue to evolve to the point where Mozilla is irrelevant; and Galleon will do the same for the GNOME camp. Both projects have Email/Groupware clients that are superior to the "extra" bundled Mozilla features anyway.
Ok, so this is old news, and my bitching won't re-write history. But I've not voiced my thoughts about this in the internet before
Macka
It's time people realize that it makes no sense whining about the work other people do for free to provide software they want or need, and expect those people to work on something that matters less for them.
Read again. What he wrote was "that are extending the traditional "web browser" into something we cannot even fully comprehend yet." It's not the individual projects. It's the sum of the environment and interactions and way of working with it that the new projects are creating that we can't fully comprehend yet - The same way that most of us didn't comprehend what the web would become when we were using early browsers in the web's infancy, even though the technology is essentially the same.
Is just browsed through the white paper, and I'd say that just using this to run CGI in development is quite narrow-minded review of it's possibilities. Of cource I've might misunderstood something.
I've looked into Jini lately and that seems to be quite interesting. I just wondered, could this be a way to use Jini based services on net via browers. There aren't probably any yet, but plugging Jini -services to brower might by a killer. Jini might be one good technique for doing 2nd generation Internet services.. Services that are dynamic, not-flashy-html-www stuff which makes it real hard to actually USE the information on the net for anything else except human browsing.. Well this might be quite far feched, but I'd say that anyone who has thought these things might have some clue about what I'm talking about..
And if that matters, it's trivial to split the connection management into a separate daemon.
> I'm annoyed by all the people that just whine;
> help out with something god damnit!
Why should we? Quite frankly you deserve a good roasting for taking what should have been an MS killer, then sitting on it and fiddling with the engine; adding bigger wheels, better spoilers, windscreen wipers, go faster stripes and fluffy dice
When you eventually ship V1.0, you'll deliver a product that will be the Open Source equivelant of MS Word. i.e. 10% of the features will be used 90% of the time. But that won't matter, because so many people will have settled on IE, or will be getting by with Konqueror, Gallion, or Opera that Mozilla will make little more than a plop, never mind a splash.
If this all sounds harsh, then it's meant to be, because I'm annoyed, and because I have a right to be. If I'd know it was going to take this long 2 years ago I'd have invested the time to learn C++ and chipped in
Macka
I think this is more for being able to run stuff like freenet, or view man pages and stuff. It just let's you use any protocol you want. You could view you files of NFS files eisly in the browser, or even run ls and get the output on the browser edisly, this isn't bloat either beacause it all 100% modular.
Doesn't it strike you that Mozilla is actually competing with the KDE & GNOME projects here? Tell me why this is a good thing?
Macka
There is a bug reported about JavaPlugin been loaded at statup. (bug 26516). And there are people working on it.
There are people working on startup performance.
And there are many reports about performance in general that are beeing addressed (Performance problems)
I hope someday Mozilla will be the Browser of our dreams. We can all help this to happen by reporting bugs, correcting them, or promoting Mozilla project.
MOD THE CHILD UP!
They are ! If you'd read the article you would've seen it was being developed by mozdev, not by the Mozilla team.
As MKB says, I'm surprised I have to explain this. ;-)
Anyhow, you can read all about it at http://www.cs.ubc.ca/doc/world/exec/intro.
Sounds like a step in the right direction.
Years ago, netscape had "all" the protocols:
ftp,http,gopher,and mail.
Now we have many streaming and file sharing protocols which are cludged into netscape somehow.
If mozilla fixed this and had protocol plugins, life would be great.
Sure.
localcgi:/dos/format?c%3A
Does it have to be only for development? Assuming it can be done safely, imagine using local CGI scripts as an alternative to local shell scripts. This becomes particularly relevant for your casual users, epsecially as a means of establishing Linux as an OS for the computer novice. Imagine J. Random User being able to use Mozilla as their program launcher -- everyone and their mothers've already learned how to more or less use web browsers.
And using the web browser as an interface is certainly not a new idea. Even before IE sprung up (and the infamous "The web browser is part of the OS" statement along with it), we had software packages like SATAN doing this back in early '95. And if we look at the web browser abstractly, as a mechanism that allows files to be selected, retrieved, and viewed, its origins can be traced back to products like Norton Commander.
I think that is actually the whole point. If you can rm -rf so can any mischievous web page author over whose sorry ass^H^H^Hpage you might stumble. And that's a bad thing. This kind of security is about securing the client against the server, not the other way round. Thus "securing ports" or whatever is entirely irrelevant here. The only port to secure would be outgoing 80. And if you do that, you basically shut down any browsing...
This browser wouldn't "voom" if I put 4,000 volts through it. Don't believe me? Read this..
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
ack!
________
Quote:> ... it looks like a glorified version of yet another client-side scripting tool like JavaScript. Do we really need this?
No, it looks like another waste of time.
I wonder... I've always wanted to be able to distribute client software that just needed a cdrom and not a website. This might just be able to fill that need...
-Moondog
It's as unsafe as any software, anyting can delete your files. Just be careful where you get your plugins from(or all your free software).
Sounds just like ActiveX. Is there any code signing involved? How do I know if I trust the CGI script that is being downloaded? If this were actually implemeted by public websites, what is the process for securing the CGI code during transfer?
Seems that people that don't like ActiveX shouldn't be to happy with this new feature. But it has worked well in IE for 3 years.
I'm not sure I completely understand this, but does this mean that mozilla could be used as a FreeNet front end, with only a few lines of code? Or even be used to as front end to napster with a bunch of code?
Generally it's used to point ftp to a real FTP client (Interarchie being popular) and afs to an AFS client (Apple File Sharing.) However it can be used for about anything, including hooks to scripting languages (AppleScript, Python, TCL) using the built in Open Scripting support.
Open Source is great but it didn't come up with this one first.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
that is to make up for the fact that windows doesn't have a reall web server (yes, yes, I know that apache can run on windoze).
I was doing a bunch of cgi crap on saturday night and I was grumpy because I was going to be gone for a few days and I wasn't going to get to work on my ideas until tuesday. But as I was checking my mail and Slashdot before I left, what do I see but this wonderful thing that allows me to do my cgi on the road! I just don't want to really run a web server off of my laptop.
Zontar The Mindless,
Il n'y a pas de Planet B.
Of course, it's a security nightmare as you couldn't tell where the file had come from. Perhaps the files could use some form of authentication. Hmm. Yes, for example, NT users could "sign" launching controls then, on a company based intranet, they could launch programs as required from any networked machine. In unix, it could be used to launch programs running suid the creater of the launch control.
Rich
Zontar The Mindless,
Il n'y a pas de Planet B.
True, although the impression I got was that this framework would provide a nice helper app to do the magic for us. Furthermore, a CGI-based scheme would allow for easily porting apps from intranet use to local use and vice-versa. Finally, something that delves in to the realm of figuring out when to properly execute content that's trusted is something that I, personally, would feel less than comfortable writing. I would much prefer a system with some peer review.
I would think this might be a script kiddies dream. Couldn't it be used to exploit local variables?
---
Ryan Wilhelm
To clear up some misconceptions, here's a response to some of the comments on Protozilla:
-Protozilla is not an "official" mozilla.org project. It is hosted at mozdev.org, as evident from the URL. (It is not the intent of Protozilla to delay the development of a viable Mozilla-based browser, which is proceeding at its own pace.)
-"Client-side CGI" is just one of Protozilla's features, and by no means the most important. As the name susggests, Protozilla is about implementing new protocols easily in Mozilla.
-Can the "client-side CGI" be used to maliciously access your local files etc.?
Protozilla is carefully designed to prevent this. The client-side CGI feature may only be used to execute files residing within the user's profile directory, which should be inaccessible to malicious web scripts. Furthermore, the request to execute the file is a special "restricted" URL which can only be loaded by the user typing it in in a special URL box (or from a privileged script). Unprivileged scripts downloaded from the web cannot load this URL. Nor can the URL be loaded by a "dumb" user clicking a malicious link on a web page. (Only executables which are specifically designated as implementing "public" protocols will be accessible to web page scripts through general-purpose URLs.)
However, any new functionality does open up the possibility of exploits and Protozilla is far from being fully tested/audited. So use it with care!
-Some posters on slashdot pointed out "prior art". These are useful to put Protozilla in context. Here are the links:
Pluggable protocol handlers in IE (http://msdn.microsoft.com/workshop/networking/plu ggable/overview/overview.asp)
Asynchronous pluggable protocols enable developers to create pluggable protocol handlers, MIME filters, and namespace handlers that work with Microsoft Internet Explorer 4.0 and later and a URL moniker.
W3M (http://www.gnu.org/brave-gnu-world/issue-16.en.ht ml)
A lot of browsers try to do everything in one program - W3M does exactly the opposite by calling external programs whenever possible. To make this easier it contains a "local CGI" mechanism that is capable of running CGI scripts locally without the help of a web server.
Jellybean (http://wgz.org/chromatic/jellybean.html)
Jellybean is a Perl Object Server with an HTTP interface, based upon an idea by Jon Udell.
MMM (http://pauillac.inria.fr/~rouaix/mmm/)
local CGIs [...] providing cheap and sophisticated MMM interfaces for applications.
No probs - just making the point that you can already do this on a domestic desktop.
Greg
(Inside a nuclear plant)
Aaaarrrggh! Run! The canary has mutated!
have it execute rm -rf /home/user or deltree -y c:\
Only the State obtains its revenue by coercion. - Murray Rothbard
Lynx has done this for a long time (though you have to reference the script as LYNXCGI, iirc; I used it a few years ago to write a script to browse manpages through lynx). It's pretty useful if you want to use cgi scripts and junk for local documentation, but don't want the overhead of running a full web-browser.
Given Java Servlets and Sun's JSP taglibs, who needs PHP?
PHP is a fossil, a relic of the late-90's
As is C++ (flamebait!!)
I gots ta ding a ding dang my dang a long ling long
Web server.
I believe it was meant to be some sort of memorial. Come on... show just a *bit* of respect for the brave men and women who died on that mission. Even in the faceless world of /. people should have a few shreds of respect for the dead.
Man is born free; and everywhere he is in chains.
Hmmm...
Do you program at all?
PHP is a language.
"CGI" is NOT a language.
PHP on many virtual hosting environments is running in CGI mode.
Please put a bit more thought into the next post before a knee-jerk post like this. "PHP is great, CGI is bad!". It's not even apples v. oranges, because at least both of those are fruits.
creation science book
Er, you dont get it i'm afraid - this isnt the equivalent of javascript (a client side script). There isnt any point trying to get web site viewers to run cgi's in their browser when thats what the server is for. This is for testing scripts.
Having said that I still question the value of this for testing, as someone else pointed out it if it doesnt mirror the server you are going to use then you still might have to make changes when you upload it.
I run apache with PHP,SSI,CGI support on my p133 40MB linux box and it works great so i'm not sure of the value of protozilla (especially given the resource requirements of mozilla!)
no sig.
What I'd like to see the mozilla team is to invent a browser that does not suck up all my system resources. I just want a browser. A simple browser that runs on UNIX / Linux. That handles html 4.0 as well as Java and JavaScript and can do netscape plugins, like real audio, mp3, midi, flash and wave files.
Mozilla .7 was still to bloated to run at home, after installing the jvm. Personally I think that the jvm that they are using sucks butt. It launches about 30 threads that just take up all my memory. Why????
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
CGI, under UNIX, is the best method of allowing
secure dynamic content creation in the case of
multiple users. mod_perl, mod_php, etc, do not
permit security boundaries between the users.
Even if it's technically correct, I've seen about 20 posts here already saying things like 'CGI sucks - PHP rules!' (I'm a huge PHP fan btw, this is not a PHP slam).
Although the mozilla people mention using it to test CGI programs locally, that seems probably the worst use of this technology. MUCH more interesting would be to tie in existing code (perl, javascript, etc) into one cohesive app, and run it *locally* with the mozilla app as the interface. No need for a net connection at all - you could write apps in Perl and distribute them to be used with a standalone Mozilla machine. Yes it could be done now if you're also shipping a webserver, but this is less to install and maintain.
Think standalone kiosks for starters. I was given a demo of a standalone kiosk system over a year ago (never got off the ground). The machine it came with was an NT box with VB Scripts, SQL server and some other stuff - huge $$$. Yes, you could replicate all of this with Apache/Mysql, etc. This just seems to make it even easier. Rather than treating the browser as just a client, it becomes more integrated - it becomes the app itself. Also, by using this IPC stuff, my Perl scripts can do one thing, my javascripts can do something else, and the mozilla frontend would tie it together (that's my impression, anyway).
I personally am becoming disenchanted with the whole mozilla thing - yes all this stuff is cool, but I think we all just wanted a decent browser about a year ago. Yes, keep developing and adding on, but a small, quick browser (with a netscape 4.7 compatibility toggle switch!) would have helped stave off the decline of this browser technology.
creation science book
mod_php and mod_perl by definition do not use the CGI interface. It is true that perl and PHP may be run as CGIs, but that is utterly different from mod_*, which involves running them with the privileges and address-space of the webserver.
I stand corrected! :)
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
... and Windows comes with Personal Web Server, which gives you an (admittedly poor) ASP & database facility. Useful for testing when poor decisions from previous staff lumber you with ASP :(
Greg
(Inside a nuclear plant)
Aaaarrrggh! Run! The canary has mutated!
--
Now that I've read about the ability to support additional protocols/urls, I'm revising and extending my remarks:
:-)
Ok, it's somewhat cool, but how about making Linux Netscape take less memory, and not crash every twenty pages before adding these new features?
So, why would we want to do this? Wouldn't it make it easier to develop on the server, where you can control the environment? Isn't the PC dead?
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
Being able to do it right inside the web browser is a great idea. Now, lets just hope it isn't as buggy as JavaScript!
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
It's a trap, designed to look like something at RedHat. It actually resolves to 209-209-49-202.oakinreach.inreach.net
Most web sites are Java-based
It is foolish to write a site that depends on java. That mistake is right up there with using Microsoft tools that only display properly on Microsoft browsers. (Unless you're Microsoft, of course. For them it's good marketing.)
One big reason is that a significant fraction of the potential audience browses with java and javascript disabled due to concern over security flaws. (Given that there's a netscape hole that lets a hostile site set up a server on YOUR machine to publish every file you can read, AND notify the hostile site that this is up and running, it's a reasonable concern. B-) )
So if you want a web site to reach the max audience, either forget java or provide a non-java alternate functionality.
CGI runs on the server, so you only depend on the client browser's ability to display.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
CGI means.. Common Gateway INTERFACE. To many dumbasses out there think CGI is a C program or a perl script or whatnot.. It isn't a program, its an INTERFACE. All web languages use CGI, java, mod_perl, mod_python, everything. When you put text in a textbox, and hit submit, thats normally CGI. (unless the form uses mail, or whatnot).
.021 seconds for php to server a page that says, "Hello World". :)
/usr/ports/www/apache13-ssl;make install
/usr/ports/www/mod_php;make install
Now personally, is this Mozilla idea a good one? Probably not, only a serious developer would need this, and a serious developer already has a webserver on their LAN. And if you are worried about being on the road, make the web server accessible via SSL and some type of login method. If you don't wanna do that, put apache on your web server. On my pentium 75 laptop, with 16 megs of ram, it only takes
Ohh wait, are you complaining that a web server is too hard to setup with ssl?
cd
cd
damn, that was too much effort.
This Protozilla project is in no context official! It's a Mozdev project, therefor it doesn't have anything to do with Mozilla.org! So, why is the topic "Mozilla.org releases Protozilla"?
-Håkan
Note that this is not an "officially blessed" mozilla.org release. This is a release by a third party, on the mozdev web site.
Also don't forget, in order for the script to run, there must either be a compiler (as in perl) or the executable must be compiled for that platform. I.e., this idea sucks, and I beg someone to convince me otherwise.
For the greatest flexibility, the central star-point of a communications I/O multiplexer has to be the operating system, not a windows manager as in W95 (partly) nor an application as in Protozilla.
We're seeing the same old and discredited mistakes of yesteryear repeated here. Yes, this makes Mozilla vastly more powerful, and it is easy to see how its developers would appreciate such a facility for experimental purposes, but for the end user it is the wrong approach. Architecturally, it is the wrong design, and pragmatically it's the wrong thing to do as well: when Mozilla crashes, you do not want a pile of network services to go down with it.
Yes, I know it's advertised primarily as a hook for experimentation in protocols, but if any real service is ever delivered over it then we all lose.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
I think this represents one of the few flaws in the Open Source philosophy. Because developers are working on their own time, they work on whatever suits their fancy. More often than not, this involves some great new feature that's completely unnecessary, but rates high on the "cool-factor". So the things that really need to get done are delayed.
Netscape's programmers are paid to work on Mozilla. I would guess about 80-90% of the Mozilla development team is Netscape employees. So in other words, yes, Mozilla is open source but it is most definitely not a volunteer project. And I can tell you've never visited the bugzilla site, because bugs that interfere with functionality (crashing on startup, etc) always get highest priority and are usually the ones to get fixed first.
I agree with you in that the bloat is excessive, but it's really beyond anyone's control at this point. I can only hope that they continue with the bug fixes long after 1.0 and make it the best damn browser suite they can.
Based on the history of the project, I believe it can be done.
While many readers have taken pains to point out that this is really a mozdev project, and others have opined that this is great or just a yawn, we may have missed the overall point here..
Since mozilla's architechture is open and documentated, we are begininng to see more and more projects (been to mozdev lately?) that are extending the traditional "web browser" into something we cannot even fully comprehend yet.
Mozilla itself may not be ready for prime time, but the *concept* of a stable base on which to build other nifty tools is.. well.. like LINUX itself.
Way to go mozilla team. Hopefully next year, we wont have to have these "its too bloated" and "no its not, its our savior" arguments anymore - we can just sit and surf like we should.
..Brent
"We should not enthrone ignorance simply because there is so much of it."
Moderators need an additional choice: "Karma Whore" for people who cut-and-paste articles as their comments!
While this is true, how should Protozila know which parser to start? And if it would start the right one, let's say PHP, how would it emulate the differences between the "pure" CGI version of running PHP and the mod_perl one?
Alexander Skwar -- Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die
Please make browser that works ! (and dont add another uselless feature)
GiraffeSville, a place anyone can call home
Mozilla.org didn't release this, it was someone's project at MozDev. You clearly know this, since you linked to mozzev.org.
I understand that this could be a nice feature and all, but a finished, functional, and [Ff]ree browser would be even nicer. Note that Netscape = 4.x is not functional (I've had to write cross-browser Javascript, and lemme tell you, NS is _not_ standards-compliant in any way, shape, or form). Opera is shaping up to be a very nice browser, but it's not free (as in beer), so I can't expect people viewing my websites to use it. So basically, if one of my clients wants to do something really cutting edge with their website, right now I have to tell them, "Fine, but that functionality is only going to work in IE 4 or 5, or Opera 5". I hate doing this, because I despise Microsoft. I keep checking back at Mozilla's site, waiting for the damn thing to get out of beta. But everytime I hear about Mozilla, it's "Mozilla added this great new feature...but they're still in beta."
I think this represents one of the few flaws in the Open Source philosophy. Because developers are working on their own time, they work on whatever suits their fancy. More often than not, this involves some great new feature that's completely unnecessary, but rates high on the "cool-factor". So the things that really need to get done are delayed.
This happens in a lot of volunteer organizations. In one organization that I belong to, we rotate cooking a meal before the meeting. We can generally find someone to cook, but it's very difficult to get people to clean. Why? Because cooking is a kind of "glory" job; if you do it right, you'll get compliments and thanks. Cleaning, on the other hand, is just as necessary, but people that do the cleaning aren't noticed or thanked.
So, in closing, I'd like to thank all of the under-appreciated people who make Mozilla a _browser_. And I'd like to tell all of the people who are busy bloating the hell out of it before it even gets out of beta to STOP killing a great product. If you really want to help, work on the rendering code, or the Javascript interpreter. Heck, just use the browser and submit bug reports so that they're found and fixed faster. Just stop killing on of the few alternative browsers that are available.
but most websites do not use CGI anymore. mod_php, mod_perl, mod_python, zope, roxen, ...
I hate to burst your bubble, but those are all built on top of the CGI standard
When I want your opinion I will beat it out of you.
Actually, some browsers support <FORM ACTION="mailto:...">, which places the URL-encoded results of the form into the body of a message and sends it. I believe Netscape started this, and I dunno how portable it is.
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
I had actually thought of this before. Only, the reason I wanted it was to be able to make an HTML inerface to programs on my own computer. I made a skinnable app for windows once, that used HTML image maps as it's skins. I think this kind of things would be really useful and flexible as a program's interface.
Please help! I'm stuck inside my virtual reality headset!
handle any existing protocols (like finger)
Actually, in mozilla, that's built in. Try finger:raduffy@idsoftware.com
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
But Mozilla + Perl/php could make for good quick and dirty, cross platform UI develpment.
Spencer Ogden
Nope. That's not how CGI works. All you need is an executable that can read from STDIN, and write to STDERR and STDOUT. Being able to parse the CGI parameters is a bonus, but not mandatory. So the Mozilla team don't have to implement a perl interpreter, or a c compiler or binary loaders or anything. Where did you get that idea from?
"moo" - cow 3, 1906
Mozdev.org Developing Protzilla
An anonymous reader wrote in to tell us about Protozilla's first alpha release. "Protozilla enables Mozilla to execute any CGI program on the local disk directly, without passing it through an HTTP server. It also allows stateless interprocess communication, the use of external programs as protocol handlers (telnet, ping, etc.), and the use of local-only pseudo-URLs (similar to about:)." This is a project by independent developers unconnected to the Mozilla browser effort that adds a lot of neat functionality.
There's no "we" in team, only "me"
Good point well made. CGI is just one of those things that most people refuse to understand, even though it's perfectly simple. It really pisses me off.
"moo" - cow 3, 1906
Form encoding is specified in the html specs. No where in the specs is this called CGI.
And as much as everyone rags on Java speed, Servlets are far and away faster than CGI.
Fh
Doesn't Lynx have something called LynxCGI that is similar inconcept?
Protozilla is NOT a new idea. Just look at how w3m gets things done! w3m uses a local CGI to do bookmarks and other things. This setup is nice because the browser executable is very small, and all the peripheral functionality is implemented in separate executables.
- CGI, under UNIX, is the best method of allowing secure dynamic content creation in the case of multiple users. mod_perl, mod_php, etc, do not permit security boundaries between the users.
I don't understand this. As far as I know, CGI scripts all run as the same user the web server is running as. Why is that more secure than PHP? More specifically, how can you claim that this puts some kind of "security boundaries between users."I suppose you could run the HTTPd as root and use the HTTP Basic Authentication info to su, but then you're running your web server as root, which is considerably less secure than running it as an unprivileged user.
So the parent is misinformative.
"moo" - cow 3, 1906
I hate to be the lone Windows 2000 troll, but... What about ISAPI? Yeah, yeah, I know, it's conceptually more insecure, could possibly "crash" the server with bad code, but.. I think it runs faster because it doesn't have to continuosly load and unload itself everytime a new request is made... it's basically a DLL that stays in memory. Any language that can compile to a DLL can be used to develop ISAPI (such as Borland Delphi).. Is there an equivalent to ISAPI on the Linux platform??
It's not an offical mozilla.org project. If you look at the link it's MOZDEV.ORG..
-Håkan
This is an example header Lynx might send to a web server.
/index.php HTTP/1.0
POST
HOST: localhost:80
Accept: text/html, text/plain, text/sgml, */*:q=0.01
Accept-Encoding: gzip, compress
Accept-Language: en
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Lynx/2.8.2rel1 libwww-FM/2.14
Referer: http://localhost/
Content-type: application/x-www-form-urlencoded
Content-length: 29
textbox=hello&submit=Test (CGI!!!)
CGI is how information from a form is urlencoded and sent to a web server. This information can also be sent via email with this..
FORM METHOD="POST" ENCODING="text/plain" ACTION="mailto:bgates@microsoft.com"
If you want to see what CGI really means and what is CGI and what is not CGI, please refer to the CGI spec. CGI refers to an interface that requires a set of environment variables to be set, passes in POST and PUT information via stdin, and returns HTTP response results on stdout.
This allows almost any language to be used to write CGI programs (C, perl, tcl, bash, whatever you want). But it doesn't imply that every interface to the HTTP protocol is CGI.
- it can run ASP, do all sorts of database stuff, etc, locally without needing a real web server.
But... but... if you're doing ASP programming, you're already not running a real web server!(Unless you're running Halcyon's Java-based ASP engine under Apache Tomcat, but that's just the first step on a road to madness.)
This is OpenSource, right? You're not my manager, right? If I want to spend my time writing the 101th mail client, it's my right to do it. Who are you to tell me where I'm supposed to spend my free time?
If you want to join and existing mail client dev. team, you are free to do so, but don't go around telling others what they should and shouldn't do.
Je ne parle pas francais.
Jon Udell had a similar idea at least two years ago (see his book, Practical Internet Groupware).
There are plenty of programs out there that can work well with just an HTML+JavaScript interface, especially if you have a small database (even a DB_File!) on your machine, and an interpreter for a scripting language like Perl or Python.
I'm curious to see whether it does anything more than Jellybean can... there's something compelling about a tiny local web server with the power of mod_perl and a simple interface that lets you build persistent, network aware applications that can replicate data between clients. With XPCOM, it's certainly possible to write a nicer interface than one that only has HTML Form widgets and some onClick handlers.
--
how to invest, a novice's guide
Uh, not all of them are. First of all CGI implies one process per request, which isn't (I believe) true of PHP, nor do I believe the Zope engine or mod_php to be "built on top of" CGI in any way. They use an interface similar to CGI but only in the sense that CGI is basically trivially obvious. Also, Java does NOT use CGI at all. I've never seen nor heard of a Java CGI program, although again it would be possible. The Servlet API is the usual alternative in Java, which uses an interface quite distinct from CGI to glue together HTTP and Java code that produces HTML or other documents.
No, it really isn't. The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web servers. It has nothing to do with the urlencoding of the form data by the client. See here for a link that backs me up. This page comes top of a google search for "cgi".
"moo" - cow 3, 1906
Another great idea from the open source community, in my opinion. Something like this has been waiting to happen, and I don't know about other people, but for me, getting a good way to some of these web programming things has been a real hinderance to me finding time to learn it. Hopefully, this will open the door to people with less resources, both financially and knowledge-wise. Now just if mozilla could get their mailer working right... :)
mod_php, mod_perl, mod_python, zope, roxen,
greetings, eMBee.
--
Gnu is Not Unix / Linux Is Not UniX
Hey. I don't post too many comments, and generally like to keep my mouth shut. However, after seeing the title of this article for no more than 3 seconds, I thought of one *ingenious* thing.
When I think of "Local CGI executable" ; the word "exploit" comes to mind. I realize that it would *only* result in "user" access, because most people run their browser when logged in anything but "root" -- but still it concerns me.
I hope some of the guys from the OpenBSD project take a look at the code, so as not to release any remote-exploits due to a certain web-admin.
That is all.
Yours,
Matador
9930262 on ICQ
The interesting part is that all browsers handle this mailto a little differently. Some (MSIE5) put the encoded form as a quopri MIME attachment. Netscape for Mac just slaps it right in the body of the mail. I haven't even tried Opera and more esoteric browsers yet. But I did have to write a Python MIME/mail processing module that can hopefully handle 99% of formats out there. I think we can open source it soon! Yay!
---
I just compiled my daily build of Mozilla a few hours ago, and while I havnt yet tested it, As a hard core mozilla user, and bug reporter, this should really spark some attention to Mozilla, since this is something that even 'the great and powerful IE5' can not do.
It doesnt seem to be in Mozilla yet, after reading the article, and tinkering with my new build, but still a wonderful idea. But how can it interact with other files that need to be on the server that you dont have? And what if you dont use absolute URLs? Im curious to see how it handles stuff like this.
Mozilla is really getting stable, I know some peoples opinions of Mozilla are tarnished, but seriously, give it a try, its come a long way in the past 6 months, I havnt used anything else in months. And please dont compare the current Mozilla tree to Netscape6, They are not the same thing. Netscape took Mozilla M18 (which is old nowadays) and messed up a very decent product. Try out the nightlies, then if you want to flame it, your at least qualified to do so.
And lets not forget that Mozilla 0.8 is supposed to be released the first week of Febuary, 1.0 is expected as early as Mid-April. We're almost there!!
Linux: Because a PC is a terrible thing to waste.
James Brents
I first remember seeing this functionality in Sun's HotJava browser (the default browser in the later Solaris versions), if the security settings allowed it.
Because it's so hard to run a web server on your development machine! Whatever.
And how well will you be testing your CGI, if you're not running it in the same (apache/thttpd/whatever) environment as the real server? You'll probably end up wasting more time modifying your code after the fact than it would take to set up a local web server!
Wow, I must be in a bad mood today.
Of course you are free to do what you want. I was not telling anyone what to do. I was just making an observation.
To clarify the point I was making, if there is an program that does 90% of what you want you can do one of two things. Join the project and add the other 10% or rewrite the 90% and then add your 10%. Quite often we end up with the latter.
The unfortunate side effect is that you end up with a lot of programs that are almost the same except that they have a few features that are different. The only people that will want to use your program will be those people that have exactly the same requirements as you do.
If the effort to create these many versions were combined there would be fewer programs but with a lot more features. More features means the program would be useful to a greater audience. Isn't that what the open source movement is all about?
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
For those afraid of the security issues associated with running CGI scripts locally -- this is a development tool only. In order for a script kiddie to misuse this, (s)he'll have to send your the CGI script in the mail, and tell you to run it for him :). Unless you're running Outlook, you're ok ;).
----------
Never underestimate the bandwidth of a 747 filled with CD-ROMs.
Fine. You can use Protozilla to run Java apps instead of CGIs, too. Protozilla is a way to execute arbitrary code from your web browser using URIs, provided that you have authorized a URI handler to execute that code.
There's no "we" in team, only "me"
As Joe Bob Briggs says, I'm surprised I have to explain this.
--mkb
For anything meant for a market, I don't think it's good. However, it could be useful for experimentation. The first thing I thought was "security hazard". Looks to me like a developertool, not consumer-technology.
//rdj
No one can understand the truth until he drinks of coffee's frothy goodness.
--Sheikh Abd-Al-Kadir, 1587
This seems to be rapidly moving away from the Unix philosophy of 'lots of small tools which do one job each, and do it well' to the MS philosphy of 'lets stick as much in as we can, it doesn't work, but hey, it's cool!' I'd rather have a small, fast, RELIABLE browser, and perhaps a small userspace HTTP server which could be run as a single user process by a user. Removes complication of setting up apache or whatever, but allows website testing in a proper server environment. Hmmm.. theres an idea. Just off to sourceforge...
Correct.
All web languages use CGI, java, mod_perl, mod_python, everything.
Incorrect. There exist several other interfaces to use for dynamic content generation. ISAPI, NSAPI, and fastCGI are all faster alternatives.
When you put text in a textbox, and hit submit, thats normally CGI.
OK, you're quite some way from the truth now. When you put text in a text box and hit submit, you are performing a HTTP GET or HTTP POST. Whether the web server then uses CGI or fastCGI to interface with an out of process executable, or one of the many ways of dealing with the request in-process, has nothing to do with your form.
(unless the form uses mail, or whatnot).
You've finally lost me there. Could you explain how a form can "use mail". Surely you aren't talking about hyperlinks to mailto: URLs, which have nothing to o with forms?
"moo" - cow 3, 1906
From the mozdev front page:
While this project is not being developed (or released for that matter) from within mozilla.org itself, it and other projects at mozdev demonstrate how mozilla technologies can be used and extended and how the community of mozilla developers has and continues to expand "beyond the browser".
--Asa
Napster uses this with internet explorer right now. Check it out.
(You need IE and napster installed for the above link to work.)
Burris
While I applaud innovation, as a practical matter I don't expect things like this to have much effect until they're nearly univerally used. Customers aren't interested in coding umpteen versions (at umpteen times the cost) of their sites to accomodate each bell and whistle available. They end up saying, "make me one version that plays to the least common denominator". And so that's what happens. At the most, they'll permit the use of a few fancy features (like Flash) that many users have or can easily get.
from the white paper:
Protozilla enables Mozilla to execute any CGI program on the local disk directly, without passing it through an HTTP server. One can think of this feature as "client-side CGI" as opposed to the usual server-side CGI. This feature may be useful for testing CGI programs, or for implementing applications that use Mozilla as a UI platform, rather than as a HTTP client. For example, if you have a Perl script that parses your e-mail, you could choose to have it display its output in the browser. In addition to the usual scripting languages, Protozilla can also execute Javascript CGI programs.
Wow -- the Mozilla team to implement a perl interpreter!
Besides, if you want to execute client side programs why not use Java applets which are portable, secure and already there today.
This is one of the problems with open source. Someone creates a variation of an existing technology/program because they don't like this or that about it.
Why not enhance the existing program rather than starting a whole new project. This is why we have 100 mediocre email programs for Linux instead of a half a dozen great ones. Everyone thinks they can do it better or is too egotistical to work as a member of a team.
End rant.
Whew, it's great to get that off my chest.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
Hey, aren't the security conerns pretty much the same as ActiveX controls? I mean you could choose "security levels" as it is with Activex.
Moderators are assholes, today. This is *funny*. Even if bob is a respected troll, the rating should be applied to the content of the posting.
And, btw, bob is trying to get the less possible karma. So modding him up is the best way to piss him off.
Cheers,
--fred
1 reply beneath your current threshold.
But thanks for the information about the ACTION=mailto: thang. I didn't know you could do that.
"moo" - cow 3, 1906
OK, so I recently discovered PHP too, and I think it's a lot better than plain Perl CGI.
But you should see CGI as a low-level protocol (the Common Gateway Interface) for transferring data, not as "a webscripting environment for Perl".
And you should (definitely) see PHP as a high-level language using the CGI protocol internally (to transfer form data, mostly).
I guess it's valid to compare the difference between PHP and plain CGI to the difference between Bonobo and plain CORBA (for as far as I know Bonobo, this seems quite a useful comparision).
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
I've a hard time seeing exactly why I would need this...
I'm serious about the Web development I do; HTML, JavaScript, some CGI in ksh and oratcl... I'm about to dive back into PHP. OK, that's not CGI, but you'll understand why I refer to it in a few moments...
Now, when I'm doing a script in ksh, I can almost always run the script from the command line and see the generated responses coming through std out.
No need for any "client-side CGI" or emulators, or anything...
For other stuff, or if I really need to test over http, it's just sooooo simple to set up Apache on, for example, 8088 (the port, not the CPU) and test "for real" so to speak.
Everybody should be doing this! I recently ran into some pages with missing images. When I got in touch with the "webmaster", his reply was "Looks OK to me... can you go take another look?".
The problem turned out to be, he checks his site over the file system, so images with spaces in the filenames still display... but over http, they don't.
All in all, this "client-side CGI" looks like a waste of time for the people working on it (or is it like teaching Gothic syntax to 12 year-olds? Worth doing as an exercise simply because of its difficulty...) and a would be a waste of time for me to try to install it on my own machines.
Protozilla wasn't released by Mozilla. It was released by MozDev.org via the Alphanumerica/Collab.net merger. They have been pushing Mozilla stuff ever since.
Protozilla is great stuff. There is some really cool stuff you can do. For example you can write javascript or a bash script within Mozilla to do crazy stuff.
I created a cups:// protocol for the Common Unix Printing System. Basically since cups runs on a non-standard port I can just do a :
cups://localhost
which is cleaner IMO.
There are some significant security concepts here. Your web application could use XPCOM and XSLT to build a full web application BUT use different users to request subsets of the same content.
For example... My primary psuedonym could request the first part of my document (cars) then on the second part it could request contra-band like DeCSS et al. This without having my car psuedonym exposed.
Good stuff. Here comes the semantic web!
Who said creative software development is dead?
I'd really like to see this happen, but it is has to overcome great obstacles, of complexities of webware.
Nifty. Should make it easier to extend Mozilla with new protocols. Mozilla could well become the browser of choice for file sharing.
IE can already do this in the beta .NET stuff.. Not only that, it can run ASP, do all sorts of database stuff, etc, locally without needing a real web server.
bug.gd: error search engine. Humanity working together to solve all errors.
What are your statistics to back that up? Anyway, the point of this is not necessarily to have a local development environment, but as another way of blurring the boundries between serverside and clientside programming.
Personally, I use a lot of modules with my cgi development, and it wouldn't be worth the trouble to get them all working (and the database hookup) on my local pc when we have everything we need on the development box. But this could be a reasonable learning tool for some people.
I'm sure with a little work you could add in a free java servlet environment. The code is open, after all.
Peace, or Not?
... it looks like a glorified version of yet another client-side scripting tool like JavaScript. Do we really need this?