MCBastos wrote:
Interviewed by CNN on 04/07/2011 18:16, Rufus told the world:
I do fully understand that in the case of SM I'm talking about a *brand
new* product - that certainly isn't "impossible" or "not allowed", and
there are a whole host of non-Apple branded browsing apps on Apples
store ranging from iOS mobile versions of Opera to iCab. Mercury is
garnering my attention over Atomic, and there is a Chrome-like one that
looks pretty nice to me too.
It's just a matter of wanting to bring a brand new product to
market...if the answer is "no", then that's the real answer and I can
live with that. I'll just have to shop elsewhere for what I want, but
that won't (and shouldn't) stop me or anyone else from asking for what
they want.
OK, let me try to parse it in very small pieces of information so you
can digest them:
There are basically two things that define what a Mozilla browser is:
the rendering features (speed, standards support and such) and the
interface features.
The rendering is defined by the Gecko engine.
Apple does not allow an iOS app to have its own HTML rendering engine.
Apps can only use the built-in Webkit engine, the same one Safari uses.
Apple won't digitally sign a Gecko-containing app, and Apple won't carry
it on the AppStore.
The only way to distribute such an app would be through alternative
stores such as Cydia. The problem is, those are a very small fraction of
the iOS userbase. So it's a lot less attractive market.
So a Gecko-containing Firefox/Seamonkey is plain out of the picture.
I got that a *long* time ago...in point of fact I knew that going in. A
Mozilla based app is clearly *not* what I'm asking for - I have said
previously that I know I'm asking for a new product...one for iOS,
containing the SM interface/feature set. Yes - that means *new* code;
but *same* features - tabs, Managers, integrated Mail suite - and feel.
"SM-like" is still SM, to the user.
Let's talk then about a Gecko-less browser shell, which would use the
built-in Webkit browser. That's what is actually available for iOS, not
full browsers. Atomic is a browser shell.
To me as a *user* - Atomic, Mercury, Opera Mobile, All in One browser -
are all "browsers", available from the Apple App Store. I don't care
how they work, I care *that* they work and that I have choices.
To me as a *coder* - having to use the built in Webkit browser means I
have to write less code. Which makes me happier, as I all I need do is
design an interface based on a set of feature specifications. I still
end up with a "browser" when I'm finished.
SM, Firefox, Thunderbird and any other Mozilla app all share code and
to some extent features...I see having to use Webkit as no different
from that, from a point of principle. New code, same biz model.
To be worthy of being called Firefox/Seamonkey, this browser shell would
have to offer similar user interface features to the other Android,
Maemo, Windows, Mac and Linux versions. Otherwise it's not Firefox, it's
just something different (and lesser) with the Firefox brand tacked on.
A very big feature in the Mozilla platform is the extension framework,
which allows customizing the interface and adding features.
There's a large extension ecosystem already built. An iOS Firefox would
be expected to run the same extensions available for other platforms or,
at the very least, to demand few modifications to extensions in order to
run them. Demanding extension developers to start from scratch on
iOS-only extensions is just not the same.
The problem is, extensions run on a framework called XUL.
XUL is built into the Gecko rendering engine.
The Webkit rendering engine available on iOS does not include XUL.
The extension framework in Webkit is far poorer than XUL, in fact. There
are several extension developers on record saying that they won't port
their extensions to Chrome or Safari because these browsers lack the
features the extensions rely on.
So any browser built for iOS will NECESSARILY exclude both the rendering
features and the extension framework that define the Mozilla browsers.
So, Mozilla might make a browser shell for iOS and call it "Firefox,"
but it wouldn't look or behave much like Firefox. That's essentially
what you are asking for.
So I ask, what's the point of having it on the first place?
The *point* is trying to bring/maintain a consistent user experience on
yet another platform into the SM arsenal. I have a big fear that Apple
is actually heading this way in the reverse (and not to my liking)
direction - that the Lion OS is going to make my desktop look more like
my iPad; re: full screen apps. In that case, I find *far* less utility
to using a consolidated suite like SM unless I can get SM Mail.app
presented to me in a tab (which I think I have been told is on the SM
roadmap) vice a separate window. Interface and human factors issues,
but issues which are going to have to be addressed at some point.
You're getting hung up on semantics - point in fact: two versions of
Opera -> one for computers, one for iOS. They are both still called
"Opera", even though the iOS version has limitations...and probably
share zero code; but looks and feel similar. Same for iCab vs iCab
Mobile for iOS. Think marketing, and not coding. The average user
doesn't care what code it is written in, or how it does what it does -
only that it does it. Each has functional limitations over it's desktop
counterparts, and I'm ok with that. That's just more platform specifics.
As an aside, I'm pretty sure I'm not going to like Lion and the
direction it's headed - I may even choose not to upgrade my iMac
desktop...but looking down the road it does seem like the gesture-driven
desktop OS will become the way of the future as the interface line
between tablet-type devices and desktop/laptop machines align. Anyone
that's interested in being part of that future better start
prognosticating now, IMO.
There's another, more serious point.
Mozilla is a non-profit foundation. It's not run to make money, it's run
to fulfill the mission objectives stated on its charter. Part of its
mission is to help keep the Internet open and free.
...and that's what I've been saying - it's not "impossible", or
"prohibited"...the SM team just isn't interested, for whatever reason.
That's ok too and I don't care what the reason is, but tell me the facts
and don't go telling me that it "can't" be done or that it's
"impossible" - it can be done, if someone *wants* to do it. Too many
people are out there doing so. The SM *won't*, and that's certainly
their prerogative...but say so.
Letting a corporation -- ANY corporation -- to dictate what should be
the priorities in browser engine development goes against that mission.
So, attaching the Mozilla brand to another rendering engine goes against
those goals.
Well, then *nobody* should be developing for Windows either...
I have no issue with a manufacturer setting requirements for it's own
product and interface standards. They all do that. It's up to
developers to decide for themselves if they want in on that market or
not - in/out, that's all ok by me, and just the way biz goes...but don't
tell me "can't".
And again - depending on how Lion actually behaves, how SM behaves under
Lion, and how users like or dislike both, the SM team may find it can
stop developing for the Mac altogether...which would be a shame, but
understandable - because the interface differences between Mac OS and
Windows may diverge to the point of making it an "iOS-like" interface
implementation, and drive team resources over the edge.
Just to stay on an issue that is real, it's happening now: Web Video
formats. Apple chose to side with the patent-encumbered H.264 video
codec, while Mozilla (and Google, incidentally) defend the use of the
patent-free WebM format.
The Webkit rendering engine in iOS does not support WebM (the one in
Chrome does, but it's different variant of Webkit).
If Mozilla made a iOS/Webkit browser shell, it wouldn't be able to
support WebM. Meaning that Mozilla would be lending their brand to an
encumbered solution, one that they are opposed to.
If that's the SM team biz model, that's ok. But we're back to "opposed
to" vice "impossible and prohibited". That's fine, but it doesn't seem
to be halting the folks at iCab and Opera.
There might still be a Firefox in the future of iOS, though. But, unless
Apple relaxes its restrictions, it won't render pages inside the Apple
device. Instead, it would do something similar to what Opera Lite does,
and pre-render the page in external servers. There's already talk of
such a product, partly in order to offer a browsing alternative for
phones with very little processing capacity (dumbphones).
My present thought concerning Lion is that with full screen apps my
preference away from a suite may be the Safari/Thunderbird combination.
The two are very similar looking/feeling from an interface standpoint,
and TB 5.0 just introduced some very subtle changes that are proving to
me to be *very* notable enhancements in my user experience - and some
probable bigger changes under the hood that I can't see that make it
faster. Very impressed with TB 5.0...wasn't expecting to be. And I
wouldn't expect Apple to relax any restrictions - Micro$ never has...
I've also heard/read recently of the possibility of producing desktop
machines using phone processors, and that Apple may even be developing a
flat panel television (presumably the world's largest iPad) - seeing as
how Apple now owns a chip designer and the new A5 processor is their
premiere offering that's certainly not out of the question.
In this case, a home "computer" might become more of an
"appliance"...and given the state of things like smartphones, iPads,
tablets, etc. I could see this being the future as well - machines
purpose-built/coded to do what we "want" vice what we tell them to do
because we're smarter than the machine. I'm not sure I like this
premonition, but I can see it coming - just look at the App Store...300K
apps and counting, or something like that? All for pocket "appliances"
that aren't really computers. But think of the user base that
represents...that can't be ignored.
--
- Rufus
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
