Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C064AEB.727F2772@apache.org>
Date: Thu, 29 Nov 2001 15:49:15 +0100
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: sharing microsoft experience
References: <OKEDLKGMIPDOCJHOEDEFOEOJCGAA.stevenn@outerthought.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steven Noels wrote:
> 
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > Sent: woensdag 28 november 2001 12:43
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: sharing microsoft experience
> >
> 
> > The editor I'd like to have is an editor composed for the specific user,
> > on the specific schema, on the specific context. It's a server-side
> > generated editor. And this is why I love the contentEditing capabilities
> > of IE 5.5 because they are granular to the single element and allow me
> > to restrict the content editing commands that the writer has.
> >
> > Of course, I'd also love to be able to add more abstract semantic
> > capabilities to those editing commands (instead of hardcoding even good
> > sematnic HTML into it) and I think Mozilla will be the key for this.
> 
> Yet another commercial inspiration source: http://www.xmlspy.com/products_doc.html
> 
> [...]
> Browser Plug-in
> The XML Spy 4.0 Document Editor is currently available as a stand-alone application,
> integrated into the XML Spy 4.0 IDE as an additional view, or as a Browser Plug-In
> for Internet Explorer. The browser plug-in is the only browser-based solution
> currently offered in the industry, and it is based upon open standards, such as XML
> Schema and XSLT.
> [...]

Yes, this is more or less what Xopus does (a bunch of javascript glue
around the MSXML stuff): extremely powerful but absolutely non-portable.

> 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)
 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.

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.

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!

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?

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?

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.

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

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

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

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.

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.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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