http, threads, etc. and Mozilla

[Jon Smirl <jo...@mediaone.net>]

Has any consideration been given to making Xerces use the Mozilla support
for all of this kind of stuff? Why reimplement opening a URL stream when
this is already available in a lib (Necko) that runs on 20 platform? The
same for threads and mutexs.

Right now I'm working on giving Xalan the ability to run extension functions
written in Javascript.  This is done by using Mozilla's XPCOM support.
XPCOM is a cross platform equivalent to Microsoft's COM.

You can run Javascript, NSPR (portable runtime), XPCOM, and Necko without
having to bring along the browser. And yes, all of these libs add size, but
why do you think your rewrite of the same functions will be any smaller?

Jon Smirl
jonsmirl@mediaone.net

Re: http, threads, etc. and Mozilla

[Dean Roddey <dr...@charmedquark.com>]

And,. to reiterate what I said in another post, you can write a NetAccessor
and plug in anybody's support into the parser.

And, in fact, you can do so without recompilation. The netaccessor is a
static public pointer in the platform utils class. Unlike the transcoder,
which is needed from microsecond one and must be indicated at compilation
time, you can, after calling Initialize() create a net accessor and just
point the platform utils at it and it will be used (delete the old one if
one is created on your platform.)

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"You young, and you gotcha health. Whatchoo wanna job fer?"


----- Original Message -----
From: "Andy Heninger" <an...@jtcsv.com>
To: <xe...@xml.apache.org>
Sent: Monday, July 24, 2000 11:56 AM
Subject: Re: http, threads, etc. and Mozilla


> "Jon Smirl" <jo...@mediaone.net> wrote
>
> > Has any consideration been given to making Xerces use the Mozilla
> support
> > for all of this kind of stuff? Why reimplement opening a URL stream when
> > this is already available in a lib (Necko) that runs on 20 platform? The
> > same for threads and mutexs.
>
> It turns out that there is some kind of issue with the Mozilla license
> and IP rights that causes problems for anyone wanting to incorporate
> Mozilla code into other commercial products.
>
> Adding Mozilla-licensed code into Xerces would be a problem.
>
> (There is no problem with the Apache license and the use
> of Xerces code in other products.)
>
> Other than this, looking at the Mozilla libraries was a really good
> thought.  Doing a first class job on URL access is complicated
> enough that there is no point doing it over again if there's
> a good implementation already available.
>
>
> Andy Heninger
> IBM XML Technology Group, Cupertino, CA
> heninger@us.ibm.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>

Re: http, threads, etc. and Mozilla

[Andy Heninger <an...@jtcsv.com>]

"Jon Smirl" <jo...@mediaone.net> wrote

> Has any consideration been given to making Xerces use the Mozilla
support
> for all of this kind of stuff? Why reimplement opening a URL stream when
> this is already available in a lib (Necko) that runs on 20 platform? The
> same for threads and mutexs.

It turns out that there is some kind of issue with the Mozilla license
and IP rights that causes problems for anyone wanting to incorporate
Mozilla code into other commercial products.

Adding Mozilla-licensed code into Xerces would be a problem.

(There is no problem with the Apache license and the use
of Xerces code in other products.)

Other than this, looking at the Mozilla libraries was a really good
thought.  Doing a first class job on URL access is complicated
enough that there is no point doing it over again if there's
a good implementation already available.


Andy Heninger
IBM XML Technology Group, Cupertino, CA
heninger@us.ibm.com

Re: http, threads, etc. and Mozilla

[Dean Roddey <dr...@charmedquark.com>]

A lot of this is really already done. The parser can be built into separate
DLLs, and in fact I maintain an alternative set of VC++ projects to do this.
It builds into utils, parser, DOM, and parsers DLLs. They just choose to
ship it as a single DLL for simplicity.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"You young, and you gotcha health. Whatchoo wanna job fer?"

> I'm for keeping the parser free of a framework too. But, there are some
> features you should use a framework to get. For example streaming from a
URL
> with http, https, proxies, ftp, file, gopher, etc, etc. The Netscape lib
for
> supporting this is about 400KB so there is probably a lot to this.
>
> This could be handled by isolating the code calling the framework. If you
> don't like using the Netscape URL lib you can always replace it with your
> own. In a lot of cases you don't even need the URL lib so Xerces should be
> designed to function without it. I'm just for not using Xerces programmer
> time to write yet another URL library. Think of the parser as a component
> that may need optional, platform specific supporting libraries.
>
> I'd even like to see Xerces broken down further and split the parser off
> from DOM support.  I'm having real problems with DOM performance in Xalan
> and I'd like to swap out the Xerces DOM.
>
> Another argument for using frameworks is that all of the platform specific
> issues can be pushed into the framework. That way Xerces/Xalan could
become
> pure portable C. The Mozilla Javascript implementation works this way, it
> had no OS dependencies. All of the OS specific code has been isolated into
> other libraries like NSPR.

Re: http, threads, etc. and Mozilla

[Jon Smirl <jo...@mediaone.net>]

I'm for keeping the parser free of a framework too. But, there are some
features you should use a framework to get. For example streaming from a URL
with http, https, proxies, ftp, file, gopher, etc, etc. The Netscape lib for
supporting this is about 400KB so there is probably a lot to this.

This could be handled by isolating the code calling the framework. If you
don't like using the Netscape URL lib you can always replace it with your
own. In a lot of cases you don't even need the URL lib so Xerces should be
designed to function without it. I'm just for not using Xerces programmer
time to write yet another URL library. Think of the parser as a component
that may need optional, platform specific supporting libraries.

I'd even like to see Xerces broken down further and split the parser off
from DOM support.  I'm having real problems with DOM performance in Xalan
and I'd like to swap out the Xerces DOM.

Another argument for using frameworks is that all of the platform specific
issues can be pushed into the framework. That way Xerces/Xalan could become
pure portable C. The Mozilla Javascript implementation works this way, it
had no OS dependencies. All of the OS specific code has been isolated into
other libraries like NSPR.

Jon Smirl
jonsmirl@mediaone.net

Re: http, threads, etc. and Mozilla

[Dean Roddey <dr...@charmedquark.com>]

It is. All you have to do is write  a NetAccessor object and plug it in.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"You young, and you gotcha health. Whatchoo wanna job fer?"


----- Original Message -----
From: "Juergen Hermann" <jh...@webde-ag.de>
To: <xe...@xml.apache.org>
Sent: Monday, July 24, 2000 2:21 AM
Subject: RE: http, threads, etc. and Mozilla


> On Sat, 22 Jul 2000 10:21:59 -0400, Jim Reitz wrote:
>
> >>> A lot of the parser's appeal is that it is completely
> >>>self contained and very small and light.
> >
> >I second that!
>
> Me too. But OTOH, why can't internal services (like http get) be made
> plug-compatible to larger libraries with extended services, i.e. if you
> NEED proxies, gopher urls, etc. then by all means change the
> runConfigure call and link in Mozilla.
>
>
> Ciao, Jürgen
>
> --
> Jürgen Hermann (jhe@webde-ag.de)
> WEB.DE AG, Amalienbadstr.41, D-76227 Karlsruhe
> Tel.: 0721/94329-0, Fax: 0721/94329-22
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>

RE: http, threads, etc. and Mozilla

[Juergen Hermann <jh...@webde-ag.de>]

On Sat, 22 Jul 2000 10:21:59 -0400, Jim Reitz wrote:

>>> A lot of the parser's appeal is that it is completely
>>>self contained and very small and light.
>
>I second that!

Me too. But OTOH, why can't internal services (like http get) be made 
plug-compatible to larger libraries with extended services, i.e. if you 
NEED proxies, gopher urls, etc. then by all means change the 
runConfigure call and link in Mozilla.


Ciao, Jürgen

--
Jürgen Hermann (jhe@webde-ag.de)
WEB.DE AG, Amalienbadstr.41, D-76227 Karlsruhe
Tel.: 0721/94329-0, Fax: 0721/94329-22

RE: http, threads, etc. and Mozilla

[Jim Reitz <je...@home.com>]

>> A lot of the parser's appeal is that it is completely
>>self contained and very small and light.

I second that!

Re: http, threads, etc. and Mozilla

[Dean Roddey <dr...@charmedquark.com>]

There is a *lot* to be said for a parser that doesn't require any other
package, and doesn't have anything in it that it doesn't need. So I would
argue against this move on general grounds.

Though I'm definitely Mr. Framework, and have spent the last nine years
writing my own, basing the parser on one would be a big step and should be
carefully considered. A lot of the parser's appeal is that it is completely
self contained and very small and light.

As to whether we think we can make ours smaller, the answer is yes. General
purpose frameworks always have higher complexity and more plumbing than the
simplistic services that the parser requires. The parser's system support is
about as light as it could be made, mostly being the flimsiest of
abstractions over direct calls to the underlying OS.

If these libraries are completely free, completely free of issues on all the
platforms and compilers the parser runs on, blah blah blah, then perhaps it
should be considered. But as someone who builds such things myself, I know
that they almost always come with strings attached.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"You young, and you gotcha health. Whatchoo wanna job fer?"

> Has any consideration been given to making Xerces use the Mozilla support
> for all of this kind of stuff? Why reimplement opening a URL stream when
> this is already available in a lib (Necko) that runs on 20 platform? The
> same for threads and mutexs.
>
> Right now I'm working on giving Xalan the ability to run extension
functions
> written in Javascript.  This is done by using Mozilla's XPCOM support.
> XPCOM is a cross platform equivalent to Microsoft's COM.
>
> You can run Javascript, NSPR (portable runtime), XPCOM, and Necko without
> having to bring along the browser. And yes, all of these libs add size,
but
> why do you think your rewrite of the same functions will be any smaller?
>

RE: http, threads, etc. and Mozilla

[Ed Staub <es...@mediaone.net>]

Jon Smirl wrote:
>Right now I'm working on giving Xalan the ability to run extension
functions
>written in Javascript.  This is done by using Mozilla's XPCOM support.
>XPCOM is a cross platform equivalent to Microsoft's COM.

Have you read http://xml.apache.org/xalan/extensions.html?
On the surface, it looks like you're reinventing the wheel, just with a
different brand of spokes.

Can you tell why the XPCOM approach is superior?

Thanks,
-Ed Staub