cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <stev...@outerthought.org>
Subject RE: sharing microsoft experience
Date Thu, 29 Nov 2001 22:55:44 GMT
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: donderdag 29 november 2001 15:49
> To: cocoon-dev@xml.apache.org
> Subject: Re: sharing microsoft experience
>
>
> Steven Noels wrote:
> >
>
> > Mozilla is cool etc... but if we want to build something that can stand
> up against
> > what is already out there, and considering the still cumbersome
> browser-share that
> > Netscape AND Mozilla have, going for a Mozilla-centric approach seems kind of
> > dangerous to me.
>
> This is the objection that lots of people expressed to me after hearing
> my intentions to go the Mozilla-way.
>
> Let me clear the picture:
>
> IE PROs:
>  1) widely used (more or less 80% of the browser market)
>  2) well integrated with the OS
>  3) powerful (MSXML and editing-capable MSHTML as available components)
>
> IE CONs:
>  1) works only on windows (the MAC version is totally incompatible and
> there are no MSXML nor MSHTTP components available! the solaris version
> is dead. the linux version is a myth but even if it was released, I
> assume it won't have the necessary XML extensions)
>  2) big time proprietary
>  3) well integrated with the OS (you can't install more than one version
> on the same machine: if your user installs a game that requires an
> updated version of IE there is a high change that your stuff won't work
> anymore)
>
> Mozilla PROs:
>  1) open source and open development
>  2) completely portable! (same browser with same functionality on every
> platform)

ahum - not so sure about this... but they are trying, that's right

>  3) decoupled with the OS (you can have as many versions you like
> installed, the user can install an updated version without breaking
> everything)
>
> Mozilla CONs:
>  1) lack of powerful components (poor xslt transformation, no schema
> capability, no inline editing capability)
>  2) almost neglectible browser share on win32 and mac systems.
>  3) decoupled with the OS (higher memory use, IE shares many libraries
> with the OS so it seems smaller)
>  4) development community with very low diversity and backed up by an
> almost-fake company (netscape).
>
> All these are facts.
>
> Personal considerations:
>
> 1) many editors are MAC users. Many MAC users would rather die than use
> Windows. (and many developpers will do the same once they try MacOS X!).
> In this case, all IE PROs vanish instantly.

+1, we should support Mac

> 2) powerful semantic-based editing capabilities are mostly targetted on
> intranets/extranets rather then general internet users. In these closed
> enviornments, it's not a big deal to require people to install an
> editing software or a specific browser. In this case, since IE forces
> you to have only one instance on the machine (at least on windows),
> there is a much higher chance of version conflicts with other
> browser-based products used in the same intranet.

It is precisely in these confined intranet zones that requiring 'another' browser or
switching company standards is a major PITA - I have been implementing projects in
BIG companies who were still suffering from NS3 (yes, three) ONE YEAR ago, with no
intention to switch since they had to support thousands of users...

> I wouldn't want to be the one who requires IE 6 for their editor but has
> to deploy it on a intranet where a two-years-old IE4-based webapp does
> email and calendar. Have fun porting your wonderful XML-stuff over to
> IE4!

same goes for NS, and until there is a sequel to the yet to be released Moz 1.0
release we do not know what backwards compatibility means to the Mozilla community
(really no pun intended)

> 3) microsoft is a well known for his marketing tactics. supporting one
> standard technology today might be good today, but might be harmful
> tomorrow (they found Java a nice little and useful toy back when IE4 was
> released, no harms in supporting it, look at what they did with IE6).
> What if they find javascript to be equally harmful for their business?
> or XSLT on the client side? or XMLSchema because the W3C didn't like to
> go the .NET way?

well... you and I are both developing and using Java apps on the MS platform - if we
don't see any harm in that, why would we need to stir up such FUD against MS now
then? They have an agenda, that's right. Hell, even OSS people have an agenda - being
the meritocracy it is ;-)

> 4) embeddability and branding: sure you can embed IE into your stuff (if
> you comply to their software restrictions and I think it would be a
> legal surrender knowing MS) but how easily can you customize look and
> feel of your IE-based application?

Fair enough - but I find themes or skins a waste of time since most of us don't have
the competence to whip up a really useful UI paradigm - we should leave such work to
the pros in useability labs & UI design shops, really

> Mozilla solves all these problems:
>
>  1) the source and the community is open: if Netscape goes away or is
> killed, they can't close the site down, nor they can force you to stop
> using the source code.

Several KEY developers are on the *payroll* of NS, and for sure they would need to go
after another job if NS goes down. And we all know what this can mean in terms of OSS
development, especially during times of recession... maybe they're lucky and they can
continue their awesome job, maybe not

>  2) the MPL is compatible with almost all software licenses and is
> commercially neutral (means, no virality)

agree

>  3) rebranding mozilla is piece of cake. (it was designed as so because
> AOL wanted this feature for their own marketing needs)

agree - even though Activestate still looks very Mozilla-ish ;-)

>  4) mozilla is designed for portability and open standards compliance.

come on - their XSLT support is severly lacking, the parser inside is ages old...
they do a nice job with XML+CSS - but comparing IE against Mozilla in terms of
practical, useful standards support (with some proprietary *extensions* admittedly)
still goes in favor for IE...

> Let me give you a short story:
>
> not so long ago, a small group of accademic researchers created the
> concept of the World-Wide Web. Both at CERN in Geneva and at NCSA in
> Chicago, people were writing software to implement it.
>
> A web server was written, made availabled under a BSD license.
>
> But when the concept was formalized and things started to become
> annoying from a research perspective, the project lacks support.
>
> A small group of individuals who were using the software for the own
> commercial needs found a bunch of bugs and put together a bunch of
> patches. They got together, created a mailing list and came up with
> their own release of the software (they forked the NCSA code, who was
> later discontinued!) and called it "a patchy server".
>
> You can look at the NetCraft graph to know webserver-share evolved from
> that moment on.

thanks for this - I was there as a user with my 25 floppydisks distribution of Linux
in 92, managed to introduce TCP/IP into the company I was working then, installed
Viola as a client and was very very happy with all this WWW stuff - and I *knew* I
was 3 years behind on the real hackers :-)

> Fastforward to present: are you sure present browser-share as anything
> to do with potential opportunities for a software product?
>
> With my above arguments, do you still see IE as a good platform to base
> your medium-term business plans on?
>
> Just something to consider for all of you.

Browsers are what appservers will be soon: commodity items, shipped with your
computer system. I do not know anymore why I upgraded IE5.5 to IE6 other than for
some security patches (sic). If a browser isn't installed by default on an OS (like
Konqueror on KDE/Linux and IE on MS), and the alternatives are not offering a *much*
better user experience, people will not go through the troubles of installing another
browser.

If such a CMS client is packaged as an *application*, there's a slim chance people
will be installing it because they like the features of the CMS and has a
Mozilla-based client app. If the CMS client requires Mozilla to be installed prior to
installing the client, I fear some relunctancy...

I'm not saying we should develop Win32 ActiveX components... but a browser-based
solution which only works with Mozilla is equally bad!

</Steven>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message