Peter Lee wrote:
>
> We currently have an application that leverages the browser's transport for
> communication. We currently work with IE 3.0-5.5 and NS 3.0-4.xx. I'm
> working on changes to enable mozilla and NS 6.0 support and have run into
> some issues (concerns).
>
> I downloaded source to mozilla, built it, and ran it. I took a look at the
> grabpage sample and after some modifications got it working (it was out of
> date apparently). I was able to create a new channel, and issue an AsyncRead
> etc.. that all works.
>
> I'm going to be loading xpcom.dll dynamically in the end which means I'm
> counting on Interfaces and function prototypes declared in mozilla to be
> constant going forward. Can I count on this? Can I count on the prototypes
> and interfaces in mozilla headers matching a NS 6.0 xpcom.dll ? The Netscape
> site has no information for developers regarding NS 6.0. I'm worried that I
> will get everything working with Mozilla, and NS 6.0 will not work.
>
> Why does Netscape site not offer developer information regarding leveraging
> xpcom on existing client systems ?
>
> Thanks.
Funny, I was just writing about this yesterday. See my reply in
this group to the thread: "Re: runtime/startup
loading of typelibs".
The short answer is that I don't think it is valid to assume that
you can do such leveraging. Mozilla has a limited set of
interfaces that are (or will be) frozen. It is not intended to
support being loaded and run by other processes. Netscape is not
shipping a system library here - it is shipping a browser.
Mozilla is not (at this point) claiming that the binaries shipped
by vendors can be used as system libraries.
The mozilla 'embedding' newsgroup is a good place to discuss the
freezing of interfaces.
John.
