Closed
Bug 7826
Opened 26 years ago
Closed 14 years ago
GFX depends on netlib
Categories
(Core Graveyard :: GFX, defect, P3)
Core Graveyard
GFX
Tracking
(Not tracked)
RESOLVED
INVALID
Future
People
(Reporter: bruce, Assigned: pavlov)
Details
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.
Updated•26 years ago
|
Assignee: brendan → warren
Comment 1•26 years ago
|
||
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
Updated•26 years ago
|
Assignee: warren → brendan
Comment 2•26 years ago
|
||
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.
Updated•26 years ago
|
Target Milestone: M9
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•26 years ago
|
Target Milestone: M9 → M10
Comment 3•26 years ago
|
||
This should be easy, but it shouldn't hold up M9 either.
/be
Updated•25 years ago
|
Target Milestone: M10 → M14
Comment 6•24 years ago
|
||
Moving out, milestone 20 will become a better Mozilla milestone soon.
/be
Target Milestone: M18 → M20
Updated•24 years ago
|
Target Milestone: M20 → mozilla1.0
Comment 7•24 years ago
|
||
I sat on this for months, but pavlov may actually be fixing it right now, for
all I know and hope.
/be
Assignee: brendan → pavlov
Status: ASSIGNED → NEW
Assignee | ||
Comment 8•24 years ago
|
||
yes, this dependancy will go away.
Comment 9•23 years ago
|
||
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Updated•16 years ago
|
Product: Core → Core Graveyard
Comment 11•14 years ago
|
||
I don't think this code exists anymore.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•