Don't know how up to date it is these days, but in the past I've used Protozilla http://protozilla.mozdev.org/ to associate these protocols (such as mailto:) with various offline and web-based apps.

Amazing. The page says "it's still in the alpha stages of development". You go and compare it to a product that's been in development for 4 years and has shipped 3 stable releases. Why?

I'm just taking a stab looking at the sophistacation of this program that it's probably skinnable.

Just think of what would have happened if people posted this on Slashdot!

/me quietly runs of to post on Slashdot and laughs evil laugh...

(Kidding)

As I understand it, this is a JavaScript application that runs inside Mozilla. It could probably be made to run inside any browser with a sufficiently sophisticated JavaScript engine. The Mozilla platform here is really Mozilla as powerful layout and JS engines. I could be totally wrong but that's how I see it. The thing that makes this so special, as I see it, is that it does so much of the work on the client (Mozilla + the nervemail JS code) rather than on the server like most current web apps.

--Asa

Okay, you caught me. I did use -moz-radius and -moz-opacity too. But that's in no way part of what makes this work. It's just a nice decoration. If those styles were ignored, the whole app would still work the same way. It would just look pointier. :)

"did I detect a "moz-radius" on those TDs ;-) ?"

IIRC, vendor-specific CSS is allowed by the standards, as long as the properties are prefixed by the correct vendor token (so "-moz-" in this case).

Alex

Wow, this forum totally screws up formatting...

Link to Ed Boltzer's site http : // www . stedy . com, http://www.stedy.com

erik

Well, as far as I can tell all these pages just use normal HTML with CSS stylings and have all the real work done on the server, i.e. sending completely new pages for every datasource access. This is nothing new really, I bet with a little bit work even NS 4.x could have done this. Nervemail on the other hand just sends the data itself to the client, which then dynamically constructs a HTML (or in this case XUL I think) page on it's own.

Erik. You have to like it or anything. But you're obviously missing the point about how this works.

It's not a DHTML page like you seem to think. It's a stand-alone application that's built upon Moz's ass-kicking support of standards. Look at the "features" page on the site and you will see what it is.

And I chose Mozilla *because* of its standards support - after tossing out IE for it's lack of same. I used the W3C specs as my reference while building this - and the match was perfect. How much closer to standards can you get?

The only Moz-specific stuff I used was for decoration: curved edges and transparency in the menus.

That would ba a long list. But the first two things that come to mind are:

1. An event model that really works. The W3C's event model (used in Moz) is nimble, powerful, accessable, and actually straightforward and usable. And in the few spots where there is ambiguity in the W3C spec, Moz implementations fill in the gaps with with practical and consistent solutions. And addEventListener() is just *so* much more nimble than onmouseover etc..

2. Support for extention of pretty much any DOM element as a programming object by adding custom methods and properties. IE does that a wee bit. Moz does it very thoroughly. And you can just imagine what THAT opens up!

3. While both browsers have their crash bugs, Moz is the one that holds up under serious scripting and memory loads.

I've occasionally plucked widgets out of this codebase to use in apps I make for clients. To make things work in IE takes a lot more code and time. And the code gets filled up with weird hacks to get around IE's limitations. And it's a sad thing to have to fill clean code with hacks.

I'd like to port Nervemail to IE someday. But I never would have had the fortitude to build the prototype in IE with just JS and XHTML. The hacks and cruft would totally obscure the architecture, and a clean structure would not have emerged. It's like, you could probably write a Java implementation made out of DOS batch files. And you could probably build the Eiffel Tower with bars of wet soap if worked reeeeaally hard. But you wouldn't do it.

Remember that MS invested so much in taking over the browser market to *prevent* the Web from replacing the OS.

Like many other people, the application-in-a-browser idea grabbed me back in '96 when javascript shipped with Navigator 2.0. After all these years, Moz makes it possible. And it's even standard!

Nervemail can't see your local filesystem. So there's no security concern. The most it does is some fancy stuff with sticking little XML docs into cookies to report client errors back to the server.

I've planned for Nervemail to have filesystem access someday - so it can run offline and store mail data and libraries on the client. But the user would have to grant permission to a signed script. There isn't any sneaky way to do it.

So you're safe.

> Is it possible to load "DOM code" with a single click into Mozilla

Yes. Most web pages out there do it. It's called a <script> tag. ;)

> this code could then read my files,

It has to ask for your permission to do that

> send them to the network

If you gave it permission, yes.

"But if it's so simple to extend the browser to an arbitrary application, maybe even without a notice to the user, I'm really concerned."

Kind of like an active X? or Bonzie Buddy? While It is possible to do this with XUL, but you still have to agree to download and install the app. Last time I checked, there wasn't a "Accept all XUL app installs" security preference.

While these extensions *may* cause security issues for idiots whjo install anything/everything. The implications of splitting an app, soi that half sits as a shell on your machine, and the othe lives on a server somewhere are mind-boggling.

<http://www.yahoo.com>