7826 - GFX depends on netlib

Status: RESOLVED INVALID

(Core Graveyard :: GFX, defect, P3)

Description

[Bruce Mitchener]

mozilla/gfx/src/nsImageURL.cpp calls a netlib functions directly. (NS_NewURL())
and mozilla/gfx/src/nsImageNetContextAsync.cpp calls NS_OpenURL().  This link
type dependency isn't so great.  Means that test apps like scribble and widget
which only need GFX and Widget need to drag in a lot of extra stuff.

Comment 1

[brendan-obsolete]

Warren, I'm hoping you'll take this, per our destroy-all-NS_-monsters sub-item
under "XPCOM binary compatibility" architecture action item.  If not, pls.
bounce it back to me.

/be

Comment 2

[Warren Harris]

2 issues here: (1) should gfx depend on netlib or not (by whatever means), and
(2) are NS_ functions really all that evil.

1. Perhaps gfx can be changed so that critical methods take nsIInputStreams and
nsIOutputStreams instead of URLs and calling NS_OpenURL -- force the caller to
do the opening. The owner of gfx should decide whether that's a good thing or
not. However, given that necko is much smaller than netlib, maybe the real
reason for wanting to remove the dependency (footprint) goes away.

2. We made an attempt in necko to not define NS_ functions, forcing callers to
go through the nsIIOService to do things, but as we attempted to land we built a
compatibility library because it was so inconvenient to use the service manager
to do all the linkage. We did one thing differently however -- we made the
compatibility library a static lib that links with the callers DLL (doing the
service manager thing internally), thereby avoiding exported functions from
necko.dll and the whole ordinal problem on Windows.

However, after doing this, it struck me that we just built our own version of an
import library, and a pretty inefficient one at that. We would have been a whole
lot better off had we just put the NS_ functions in necko, and provided a .def
file to fix the ordinal problem.

It is not my (and Rick Potts) recommendation that we just provide .def files for
all the libraries that define global entry points. If we ever want to evolve the
service interfaces in the future, we'll still have to support the old
service interface and provide these NS_ functions for backward compatibility
anyway.

Comment 3

[brendan-obsolete]

This should be easy, but it shouldn't hold up M9 either.

/be

Comment 4

[Brendan Eich [:brendan]]

Pushing out, not a beta blocker.

/be

Comment 5

[Brendan Eich [:brendan]]

Move out past nsbeta2.

/be

Comment 6

[Brendan Eich [:brendan]]

Moving out, milestone 20 will become a better Mozilla milestone soon.

/be

Comment 7

[Brendan Eich [:brendan]]

I sat on this for months, but pavlov may actually be fixing it right now, for
all I know and hope.

/be

Comment 8

[Stuart Parmenter]

yes, this dependancy will go away.

Comment 9

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 10

[Vedran Miletic]

retargeting

Comment 11

[Joe Drew (not getting mail)]

I don't think this code exists anymore.