AOL Moving to GeckoMonday March 11th, 2002Newsforge, and others are reporting that the AOL client will use Gecko, starting with the next major release, 8.0. Along with that, the story talked about AOL's departure from any server platform that isn't linux, and AOL's plans to release a standalone linux client (there aren't any). This has long been the rumor, and many felt until AOL started using Gecko, it would be hard to get sites to stop using proprietary IE code. This may be the kick in the pants that's needed to help get major sites to allow non-Microsoft browsers access to all of their content. Sites that I consider major are Slashdot, K5, MozillaZine, CNN, Hotmail, and all the pages I use at school/work (UIUC). Really, I do almost all my browsing in Mozilla and only really need to go to IE when there is a Flash I want to see (and only because I haven't taken the time to figure out how to get Flash working under Mozilla). What major sites out there still don't work? Sites from large companies that I've visited recently that still use proprietary HTML/JS include Adobe and Nikon. These aren't the type of sites that a lot of people visit on a daily basis, but still, they should be switching over to the standards compliant stuff. Alex Yeah, that was what I was thinking too. Those sites are by large companies who should have the resources to do better, but don\'t. Still, most people probably spend less than 1% of their browsing time there, which is why I hesitate to call them \"major sites\" Another problem site: http://www.opera.com looks like a site from 1995 - because for an unknown reason, Mozilla 0.9.8 and 0.9.9 do not load the stylesheet. I have contacted Opera about this, but have gotten no reply. This could be Opera getting Netscape back for (irrationally) blocking Opera 6 users from using Netscape Webmail with a message that says: "your browser is too old." Opera 6, however, is brand new. Regards, - Jayesh Here are the most severe Tech Evangelism bugs: http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&priority=--&priority=P1&priority=P2&bug_severity=blocker&bug_severity=critical&bug_severity=major&product=Tech+Evangelism > Here are the most severe Tech Evangelism bugs: Looks like an awful lot of them come from Mozilla breaking backward compatibility with document.layers. Hmmmm, according to comment #33 in Bug #95849 <http://bugzilla.mozilla.org/show_bug.cgi?id=95849>, even that Tech Evangelism bug could be related to layers. Hi You'll need to find npswf32.dll for Flash and np32dsw.dll for "Shockwave for director" and then just copy these into your plugin folder. As to CNN, what is the problem there? I go there often, watch any of the three formats of video, I have no problems at their site. Or you can copy all your plugins into a folder called "plugins" in your .mozilla or Application Data/Mozilla/ directory and you won't have to redo it every time you install a new mozilla build. --Asa (0.9.9's gonna rock!) There's already an AOL linux client, it's just not available for download. But it shipped with the gateway internet appliance. Joseph Elwell. I changed the wording. You know what I meant. Too bad moz.org didn't focus on the browser only and get it completed 1-2 years ago. Difficult to exagerate how unfortunate it is that so much time, energy, complexity and delay spent on news, chat, mail and compose when it's so patently obvious that all anyone needs, AOL included, is gecko. "Difficult to exagerate how unfortunate it is that so much time, energy, complexity and delay spent on news, chat, mail and compose when it's so patently obvious that all anyone needs, AOL included, is gecko." It is also "Difficult to exagerate how unfortunate it is that" so many people think that THEIR use of Mozilla represents everyone's use. I use Mail/News every day (more than once an hour during the day). Just because people are using Gecko in their products doesn't mean that they aren't using any of the components designed for other parts of the Application. For example, if it weren't for things like Mail/News the outliner widget wouldn't have been as polished as it is today, and I know that many 3rd party developers use the outliner. Gecko is clearly the most important part of the project, but Gecko has also been more than useable for a long time now. Anyone wanting to use Gecko has been able to use it for eons... Uhmm, I think AOL, which represents 30 million users is a better proxy than you. I'll take your word for it that the Outliner widget is key to browsing. Again, you miss the point. Gecko has been stable for some time now. Mozilla is a Browser SUITE and a Application Framework. Part of that framework is Gecko, and it has been embedable for years now (and as I work at a company that has been embedding gecko for years now in a shipping product, I can personally attest to this). And who cares if AOL\'s 30 million users agree with me. The users aren\'t making the decision, AOL\'s management is... The 30 million users don\'t have any voice in the matter, nor (on average) would they even be technical enough to know what the hell we are talking about. If AOL wanted it sooner all they had to do was throw more developers at it. Your comment doesn\'t make any sense. Who said AOL wanted it sooner? Your comment makes even less sense? Think, buddy. Your comment: "Too bad moz.org didn't focus on the browser only and get it completed 1-2 years ago." You then noted that all anyone needs, AOL included, is gecko. A reasonable inference is that AOL could have switched to gecko much sooner if mozilla.org had focused only on a browser. If that's the point you were trying to make, and that's certainly the impression I got, then I reiterate that it's nonsensical: AOL could have just thrown more developers at gecko to get the result they wanted sooner. "A reasonable inference is that AOL could have switched to gecko much sooner if mozilla.org had focused only on a browser." Yep. It still does *not* follow that they wanted it earlier to the point that they would put engineers on it. Why hurry up the browser when you still have a contract to use IE. Until recently AOL was still obligated by contract to use IE. AOL may have been in little rush to complete the browser, since they could not switch AOL until the contract ran out. They may also be thinking with 30+ million users, they may figure the browser may simply sell itself when they switch AOL, just as Microsoft was able to sell IE by bolting it to the OS. The main difference here is that IMHO Mozilla is a first class browser--can this be said of IE when it was first attached to Windows? Man you are boring and predictable. Did you perhaps not notice that the goal and point of the mozilla project was to build the next generation of the Netscape browsing sweet, and that therefore if all they did was build a rendering engine they would have failed to meeting their goal? Is this really a difficult concept to understand? Maybe so. That's all fine and well but the only party responsible for defining the objective is Mozilla itself and by defining it as a sweet instead of a browser, they practically killed it. They are a minimum of 1 year, if not 2 years, late with a 1.0 release. The browser wars are over for the most part. And the only useful portion of the development (assuming the AOL news is accurate) is gecko. I'm a lot less predictable than the mozilla cheerleaders, imo. \\\"I\\\'m a lot less predictable than the mozilla cheerleaders, imo.\\\" Nice trolling.... Perhaps your point would be better received if it wasn\\\'t going around in circles. Gecko has been useful for some time, and if you wanted a browser based on Gecko, try one of the browser-only products like K-Meleon or Galeon. \\\"And the only useful portion of the development (assuming the AOL news is accurate) is gecko.\\\" How does AOL using Gecko mean that the rest of the application is worthless? You could at least fully develop your argument before bothering to write. AOL isn\\\'t shipping all of Mozilla with AOL 8.0 because they need an idiot-proof browser, not a fully-featured one. AOL couldn\\\'t have switched to Gecko much sooner because of their legal obligation to Microsoft (see the DOJ filings). But what stops AOL from implementing the "missing features" of Mozilla? AOL could very well ship a mozilla with document.all and window.event. That would fix 99% of the broken sites but it won't help standards. From a "management-guy" point of view, there's little reason for not paying just a couple of programmer to add the missing javascript code for doing this. > AOL could very well ship a mozilla with document.all and window.event. That would fix 99% of the broken sites but it won't help standards. I don't know what you mean by "help standards," and I think there's been a lot of strange, almost moralistic thinking about the standards issue. What support for document.layers (the Netscape standard) would accomplish is make thousands of currently web sites suddenly work with Mozilla. Users can use their favorite sites, and concern about Mozilla incompatibility largely evaporate. That's what we call a win-win situation. > From a "management-guy" point of view, there's little reason for not paying just a couple of programmer to add the missing javascript code for doing this. That really doesn't make sense to me. One Mozilla coder could spend one to two days adding document.layers support. Or, thousands of web sites, many of which have been stable for years, could re-open their code base, search for resources to change their code, and then implement, test and deploy those changes. The former option is about twenty person-hours at most; the latter is measured in person-years. Which is more efficient? But it's not even a question of what would be more efficient for the whole human race. It's a purely pragmatic issue for Netscape. Compatibility with existing web sites is crucial to increasing market share, even given AOL backing. If they imagine that everyone is going to rev their sites before AOL 8 comes out, then they're on drugs. That's not how software built on a platform works. Much of the software is not being tended at any given time, and opening a code base presents large logistical difficulties for many organizations. Correction to two slightly garbled sentences follows. RFE: Preview button in Mozillazine... What support for document.layers (the Netscape standard) would accomplish is make thousands of currently broken web sites suddenly work with Mozilla. Users could use their favorite sites, and concerns about Mozilla incompatibility would largely evaporate. All those kludges are awful. Microsoft revealed that they have absolutely no taste for API design. Binding the event object to the global window object was a stupid decision, it's like using global variables. And making an "all" array of everything is silly too. The document.layers API is awful too, each layer is a whole document! Maintaining these kind of kludges for ever is what make the software we use more bloated. It's also something which makes software development more dificult (you can be assigned to a project coded for these). If you knew the Microsoft Windows API you would know why the APIs are important and they should not be allowed to rotten. I agree with you about Microsft's API designs. Was I advocating adopting Microsoft API? There are only a few useful things I would like to see adopted, like onbeforeunload. What I was advocating was continuing to support one key piece of Netscape API that is causing huge incompatibilities in the installed base. > The document.layers API is awful too, each layer is a whole document! And the problem with that is what? A "document" may seem like a big thing but it's just an object with a few attributes and methods. If there's some abstract parsimony argument in there, it has to take second billing to the need for backwards compatibility in platform APIs, which is demonstrably breaking the installed base of platform software. The whole point of a div is to divide a document up into seperate documentlets for lack of a better term. The NS4 layers API had a noble goal, unfortunately it was entirely too buggy. If someone could explain "ttyle" to me I'd be very grateful. :) yes supporting document.layers would make life easier, at least on short term. But on the long term life will be easier for everyone when document.layers is rotted out. The faster, the better. Sites which still think there's a NS4 vs. IE4 war should be updated some time wether it's for Mozilla compatibility sake or not. The newer standards like XHTML 1.1, CSS and DOM are beautiful. They make sense and lead to a clear structure and way of programming compatible (e.g. with textbrowsers or readers) but still very dynamic and styled sites. I'm looking forward to the time, when this is really usable and having reasons to update year old sites that block this can only help to speed it up. I suspect that the overhead of supporting layers would be higher than you think; the DOM implementation touches on an awful lot of code. In any case, unless you're sure you can quantify the effort involved, I don't think it's appropriate to say that dropping layers was the wrong call. Also remember that there would be an /ongoing/ cost involved in maintaining parallel DOM implementations, causing Mozilla development to advance even more slowly. The existance of layers is also causing an ongoing additional expense to every web designer that needs to support them. Getting rid of them, while it may cause some short-term pain, saves time and effort for both the browser makers and the web designers in the long run. Yes, some users may be upset. Some of them might switch to another browser. But most of them will probably just upgrade. Um, it's not a question of supporting layers. Those are supported, regardless. It's just a matter of the language and DOM construct used to access them. My twenty hour estimate is based on the legacy document.layers construct being a synonym for the new "standard" (i.e., endorsed by the MIT Computer Science Department, alias the W3C) construct. If that's not true then the estimate goes up. Certainly a shadowed implementation such as you suggest would be a burden, while a simple JavaScript/DOM synonym would be almost no problem at all. I haven't seen any specific argument as to why more than a synonym is needed and it's possible there are complicating factors that haven't been brought up here. The argument that's been made up until now isn't that it would be hard but that it would corrupt the purity of standards -- a pretty insubstantial argument given Mozilla support for non-standard constructs such as the horrifying innerHTML, and the pragmatic need to support the sites and applications that actually exist in the real world. BTW, if you want to see just how small a change it would be to map the old construct to the new one, take a look at this: http://developer.netscape.com/evangelism/docs/api/layer-emulation/ . It's possible to do 90% of it just in a small snippet of JavaScript. That means it would not be a lot of work on the browser side to reach the same compatibility level. Here's another page on the Netscape site worth consulting on this issue: http://developer.netscape.com/evangelism/docs/articles/updating-dhtml-web-pages/#codefork . As far as I can tell from that, there are very few things that need to be done on the browser side for compatibility: 1. Interpret the old LAYER tag as meaning a positioned DIV. 2. When someone calls "new Layer", interpret that as document.createElement. 3. When someone accesses document.elementID or document.layers["elementID"], interpret that as meaning document.getElementById("elementID"). 4. Return a non-null, non-false value for document.layers if accessed by itself. There are some sites that this might break on, but I submit that it would work on the vast majority of them. If there's any significant bustage then it could probably be fixed by returning a real document.layers collection, which wouldn't be too hard, but might start to create some of the data structure shadowing overhead. I don't think it's required. Sorry for the message bombing but it seemed like a good time to take this issue down to specifics..... "One Mozilla coder could spend one to two days adding document.layers support. Or, thousands of web sites, many of which have been stable for years, could re-open their code base, search for resources to change their code, and then implement, test and deploy those changes. The former option is about twenty person-hours at most; the latter is measured in person-years." I am curious as to how you have determined that one programmer could implement document.layers support in 20 hours or less. Have you actually sat down and outlined what would be required to complete the task or are you just randomly choosing a number that sounds good to you? I suspect that your estimation was simply fabricated rather than calculated. BTW, how is it that "one to two days" is the same as "about twenty person-hours at most" when a typical work day is 8 hours? Are you suggesting that a programmer could spend 20 hours in a single 24 hour day and end up with bug free document.layers support for Mozilla? That would be very impressive; I would never have guessed that you had so much faith in the abilities of Mozilla developers. I also wonder if your 20 hour or less time estimate includes the time required for the patch code to be reviewed, tested, and approved. Personally I would not mind seeing document.layers support become a part of Mozilla's quirks mode because I agree that it would resolve many of the evangelism bugs without causing any significant harm to the pro-standards position. There are very few new sites being developed that utilize document.layers and I doubt that adding document.layers support to Mozilla would change that trend. However, I would never presume to trivialize the amount of work required to implement document.layers support. If it would really only take you one or two days to code it, then why don't you do it and submit a patch? Mozilla.org may not choose to incorporate it into their builds, but if there was a patch then anyone who wanted to do their own build could include it.
I really think that people are going to start leaving AOL in droves soon. The prices are too high, and broadband is catching on, plus it's easy to use (and no dial-up modem). Of course it's good they are going to use Gecko, but what about other Mozilla technologies? If I may be allowed a bit of hyperbole, this is the ghost of netscape rising up and bitchslapping Microsoft. In a very bizarre way, it seems like evil dumb-it-down-for-the-masses AOL is the only non-government entity that is able to challenge Microsoft on its own terms. As much as MS is fucking with the Internet, it's ironically AOL who has been paying for development of a standards-supporting competition and now maybe we finally will see Gecko on millions of CDs across the world. How cool is that? My favorite quote: <quote> Thousands of AOL servers are already 100% Linux, and more are switching over every day. AOL number-crunchers figure they can replace an $80,000 box running proprietary UNIX with two $5,000 Linux boxes and get a 50% increase in performance in addition to the cost savings. "Don't tell our competitors," one of our AOL contacts says. "Let them keep buying expensive crap." We hear that every hardware vendor who approaches AOL is now being asked, "How is your support for Linux?" before they are even allowed to make a sales presentation. </quote> Now seriously, when are THEY going to support Linux, or do they think no linux user would be caught dead with AOL? Hmmm. If they build it, people will come, I think. W http://pengaol.org/ Well all the use I had for AOL was the connection, because other ISPs in my area (a small village in Corsica) were pay-per-the-minute at that time, but I think it's quite useful. Speedier and lighter than a full-fledged AOL client too ;) Also, about AOL vs broadband, AOL is providing broadband access too in the US, so I think they'll adapt to the situation. When AOL first hit the Internet, they took a lot of measures to make themselves responsible net citizens. True, they had a spam problem. They did a lot of good things, though. They created mirrors and did a lot of free hosting that has helped to better the net. AOL has successfully introduced many untechnical people to the Internet. That is a huge accomplishment. I like the title of this piece: "AOL Moving to Gecko." That makes it clear that AOL will not just give their users a standard Mozilla release. They will probably not use a standard Netscape release either. I bet they will just build a new embedded product on top of Mozilla, like Netscape or Galeon, and connect that with the AOL client. They might call the browser "Netscape" for advertising, but that's it. Interestingly, for Windows users, the new AOL Client would have to install a JRE, probably Sun JRE 1.4. This isn't true for the current AOL Client, which uses MS IE and presumably MS's JRE. Sun JRE 1.4 is darn good, and wide availability of it will likely spur some interesting Java development. If AOL does roll out a new AOL client with IE ripped out, and with a web browser product based on Mozilla, and with a real Java stack, the Internet will get more interesting. Technologies like XML will take new prominence, as that is the premiere markup language supported by Mozilla. Will the web become more interactive? Probably. As for an AOL Client for Linux, it will likely happen, but not soon. That kind of thing is merely unannounced vaporware at this point. As the Linux desktop begins to slowly crush the Windows monopoly--quite possibly capped in 2004 when Windows XP users learn they have to shell out another $200 to keep using their computers, or in the alternative, just download a Linux distro--more companies will start delivering their proprietary software for use on Linux. AOL will be just one among many such companies. After Mozilla 1.0 is released, at the same level of 0.9.9 or above, we will all owe AOL a debt of gratitude. That's not something that I considered likely seven years ago. Now, I've come to accept AOL for what they are and appreciate them for it. I am running .9.9 on a Win95/166/64 -- it's faster than any other browser I have on this machine, including NS 6.2 and MSIE 5.5. Megakudos to the developers for ramping up the peformance, this is insanely great. :) Please do not even SPEAK of implementing the horror that is the Netscape 4 Layer. It should not be perpetuated, period. Same is true for document.all, for that matter -- not quite as horrid in some ways, but just as antiquated. Go, Lizard, GO! Wheeeeee! :) AOl is officially starting to test AOL 7.0 + Gecko. I am an OL beta tester (like many others) and we all got the following message: "Hello Beta Testers! The Beta Team is happy to announce the start of a new Beta test -- AOL 7.0 with Netscape Gecko. The software used in this test is based on the most recent version of AOL 7.0 with Netscape Gecko as its internal browser. Netscape Gecko is an embeddable browser designed to support open Internet standards, and is used for products like Netscape 6.2 and Instant AOL. This Beta tests the functionality of the AOL 7.0 software with Netscape Gecko. Please Go to Keyword: Beta and visit the "AOL 7.0 with Netscape Gecko Beta" area, to review the documentation and download the beta software. - AOL Beta Team" AOL members who want to join the beta test, Press Keyword button and enter "beta". It will ake you to the beta application form and you will be provided with thge resto of the information. AOl is officially starting to test AOL 7.0 + Gecko. I am an OL beta tester (like many others) and we all got the following message: "Hello Beta Testers! The Beta Team is happy to announce the start of a new Beta test -- AOL 7.0 with Netscape Gecko. The software used in this test is based on the most recent version of AOL 7.0 with Netscape Gecko as its internal browser. Netscape Gecko is an embeddable browser designed to support open Internet standards, and is used for products like Netscape 6.2 and Instant AOL. This Beta tests the functionality of the AOL 7.0 software with Netscape Gecko. Please Go to Keyword: Beta and visit the "AOL 7.0 with Netscape Gecko Beta" area, to review the documentation and download the beta software. - AOL Beta Team" AOL members who want to join the beta test, Press Keyword button and enter "beta". It will ake you to the beta application form and you will be provided with thge resto of the information. Also sighted at http://www.activewin.com/awin/comments.asp?ThreadIndex=6276 (ActiveWin is a Microsoft news site that aggregates news from various sources). Alex I can't believe that any Linux users would use AOL. AOL is for dummies (in a kind sense), IMO, while Linux users are hackers who'd consider connecting to the Internet via AOL a waste of money. Are there any Linux users here who would use AOL? |