actually, in the future, i'd really like to move the networking NS_NewXXX functions into a static library. that way each component that depends on necko can contain a single copy of these helper functions, instead of one inlined everywhere it is needed. this should help reduce code bloat without requiring consumers to link to libnecko. it would also be possible to write a version of this library that did link to necko and didn't bother calling the component manager if that were desired.
darin Rick Potts wrote: > hey Jon, > > you've opened up another closet full of skeletons :-) > i believe that currently there are several different 'flavors' of > NS_NewXXX functions... most/all of the ones being exported from necko > act as public helper functions - and are designed to *only* rely on the > public necko APIs. at some point, when the necko APIs freeze, we should > probably change these functions from being 'exported inline' to just > exported 'C' functions... but its easier to leave them the way they are > for now... > > most of the NS_NewXXX functions being exported from layout/content > either pre-date our component factory story or are meant to be used > 'internally'... i'll defer to the layout group to elaborate on this :-) > > in the end, you are correct, we need to examine *all* of the exported > NS_NewXXX functions and conscious decide which ones are really public, > which ones are 'private' but need to be exported for internal > consumption and which ones are obsolete and should be removed (or > chagned over to use XPCOM component factories...) > > -- rick > > > Jon Smirl wrote: > >> Sounds like all of the NS_NewXXX functions need to be carefully >> inspected to >> make sure they only call public APIs. Most of the ones in layout/content >> violate this. >> >> I wish there was a simpler way to separate component public APIs from app >> public APIs. Should all app public APIs be required to live in an IDL >> file? >> This would allow the build process to play with the include paths and >> hide >> the non-global component APIs from the rest of the app. >> >> -- >> Jon Smirl >> [EMAIL PROTECTED] >> >> >> >
