Closed Bug 7826 Opened 26 years ago Closed 14 years ago

GFX depends on netlib

Categories

(Core Graveyard :: GFX, defect, P3)

defect

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.
Assignee: brendan → warren
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
Assignee: warren → brendan
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.
Target Milestone: M9
Status: NEW → ASSIGNED
Target Milestone: M9 → M10
This should be easy, but it shouldn't hold up M9 either. /be
Target Milestone: M10 → M14
Pushing out, not a beta blocker. /be
Target Milestone: M14 → M16
Move out past nsbeta2. /be
Target Milestone: M16 → M18
Moving out, milestone 20 will become a better Mozilla milestone soon. /be
Target Milestone: M18 → M20
Target Milestone: M20 → mozilla1.0
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
yes, this dependancy will go away.
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
retargeting
Target Milestone: mozilla1.0.1 → Future
Component: XP Miscellany → GFX
Product: Core → Core Graveyard
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.