Hello,
Some of the points remind me of when we were moving from Windows 3.1 to
Windows 95, and NT 3.51 to NT 4.0. At that time it was from 16bit to
32bit. The only way to deal with it, is to get everything migrated as
quickly as possible. I did find COM technology somewhat useful (in
Windows land) during transition, it that the x86, x64 components can
make calls to each other.
I've agree about "PDF integration" in the browser. The PDF.js idea
sounds really good! I would like to be able to view PDF without needing
any Adobe x86 DLLs, nag screens, bloat etc. Google do have a "quick
view" option for some PDFs but it didn't look very good last time I
tested it.
MCBastos wrote:
Interviewed by CNN on 15/02/2012 17:13, Gerry Hickman told the world:
Thanks for the replies,
I did expect "plug-ins" to be given as a reason for not moving forward,
but they'll just have to update them, just like device drivers had to be
updated for x64.
I found a similar thread on Adobe
http://forums.adobe.com/message/4047605
This is even more backward looking.
I'd expect SeaMonkey to be in the lead on this, not IE and FireFox.
Anyway, there were some positive replies above, and I do look forward to
seeing SeaMonkey in x64!
Gerry, the problem is not the supported plugins. As I pointed out, the
big three (Flash, Java and Silverlight) are already available in x64;
PDF is not a big problem in my view (I, and many others, would make do
without an in-browser PDF reader until such a beast is available with no
big loss). Quicktime/WindowsMedia/RealMedia are dying out, but yes, if
they saw a need they would push some sort of x64 plugin to market. Long
term, all of the above will be eventually replaced by HTML5 and PDF.js.
The real problem is the "long tail" of lesser-used, sometimes
special-purpose plugins (some of which haven't been supported for years)
which people need to access offbeat websites. Yes, those are probably
security risks, and people *should* have stopped using them years ago.
But *forcing* people to give up something is no way to gain users.
Every time a feature was dropped from Seamonkey, for whatever reason
(incompatibility with newer versions of Gecko, lack of personnel with
the ability to support/port it, whatever), there was a lot of protests
in the forum. Even if the feature was replaced with another one with a
similar role. People do get frustrated when something stops working, and
they are usually very quick to blame the dev team for some imagined
personality fault on theirs.
The naive proposed solution is "Well, then why not make both of them
available and let the users choose?" That's what Microsoft did, after
all. But the Seamonkey council is not Microsoft. They have finite
resources, and adding a fourth main build (currently there are Win32,
OSX and Linux builds) would necessarily impact negatively the other
builds. (And, by the way, IE-x64 is not taking the world by storm. Even
in the IE world. People simply don't see any big advantage in the x64
build -- there are some, but they are kinda hidden from view. And the
32bit build still has more ActiveX plugins available.)
Let's take a step back and look at it from the other side, that is,
instead of looking at what we would lose from moving to full-x64, what
would we *gain* from it.
What's the most important gain of using a x64 browser? Allocating more
than 4 Gb of RAM for the browser. How many people *really* need to do
that currently? Not many, I'll bet. Hell, not that many people even HAVE
over 4 Gb or RAM in their machines. The ones who do, have better uses
for it than letting a browser take over all that RAM. If any browser
goes over 1 Gb, even in very heavy usage, people tend to scream "Memory
Hog!" (And, by the way, Firefox memory usage fell dramatically over the
last year. Seamonkey benefits from it too, since they share the same
core. So hitting 4Gb with Firefox or Seamonkey is *less* likely now than
one year ago.)
To sum it up: having a x64-native browser would give minimal benefits
*right now,* but it would inconvenience a good number of users. The
developers are looking into it, the goal IS to eventually move to x64,
but they are waiting for
As for "Seamonkey in the lead..." be real. Seamonkey depends on core
technology developed by the Firefox project. The current build of Gecko
for Win64 is classed as "experimental." Until it moves to a stable,
supported status, there's no sense in building Seamonkey on top of it.
--
Gerry Hickman (London UK)
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
