with Scott Collins


<chrisn> now, I know a lot of people here don't know much about XPCOM, so scott, maybe you'd like to give a short intro to it (and yourself), and then we'll start the chat
<scc> OK
  I'm the current owner of XPCOM
  I've been at Netscape about 3 years
  I spend most of my time working out of Michigan
  XPCOM is our cross-platform solution to object-oriented programming, sort of
  it is based on Microsoft's COM
  and is _theoretically_ binary compatible with it
  COM, and XPCOM are essentially a set of non-compiler enforced rules
  that say what you _can't_ do
  to get some of what C++ would normally give you
  [XP]COM is both a model for selecting and loading components
  that may have been built _long_ after the app
  and a scheme for managing ownership
  via reference counting
  [XP]COM is really just the girders out of which the rest of our app is built
  and it's nothing more than some simple rules, and a little glue
<simeon> what are some high level implications with being binary compatible with Microsoft COM? As in, what can you do with it?
<scc> Hmmm, well first off, I question whether we actually _are_ binary compatible with COM
  the things we could are pretty cool
  for instance,
  we could directly support components that had been written for IE
  and work with existing OLE parts
  the main implication is leverage ... exploiting code people have already written
<dougt> hey scc, could you talk about your vision of xpcom nspr apart from the browser? Is there one?
<scc> Hmmm
  Well, first the plans are pretty public
  I've posted them to <http://www.mozilla.org/projects/xpcom/XPCOM_plans.html>
  My primary objective
  is to make XPCOM as _light_ as possible
  exploit the C/C++ standard libraries more
  Move to API's that compatible with that objective
  support the standard algorithms, etc
  I think that will make XPCOM cost less to use for typical implementors
  who will certainly, in C++ at least, be exploiting the standard libraries
  and such usage is compatible with Java iterators, etc
  The less XPCOM gets in the way, the more useful I think it will be
  As for NSPR ... that's really it's own thing, outside the scope of XPCOM
<chrisn> scc: could you talk a little bit about how xpcom will be useful to the skin and component developers down the line? For example, people like me who aren't programmers...
  not a great question, I know
<scc> The main facility of XPCOM that matters to non-C++ programmers
  is that XPT, XPTCall, XPConnect, et al make our internal APIs available through JavaScript
  which is vital to manipulating the DOM within your interface
  Because we use XPCOM for everything you might want to control
  The JS you write in your GUI has as much control as any hunk of compiled C++ could hope
<_AsA_> Hi scc. Where in the mozilla code does XPCOM live and which parts of that code are you working with the most heavily. Also, are there other parts of mozilla that are holding up XPCOM progress (making it less visible/lighter)or parts of mozilla that are being held up (significantly) by XPCOM's status?
<scc> Where does XPCOM live? -- /mozilla/xpcom
  What parts am I working with? -- currently the things I'm cleaning up right now are in xpcom/ds ... `data structures'
  Anything holding XPCOM up? -- No, XPCOM is pretty low-level, the only things that get in the way are compiler differences
  Anything waiting on XPCOM? -- actually, no! There have been some significant and unexpected speed-ups recently (thanks, dougt)
<dougt> :-)
<scc> but nobody was _waiting_ for that
  remember, for the most part, XPCOM is really just a set of coding guidelines, and a grab bag of utility data structures
  The main problem is people see the XPCOM directory hierarchy as a dumping ground for anything lower level than their own code
  so innappropriate code lands there frequently.
<Seventh> how much work would be required to add another scripted language (like Perl) integrated with XPCOM like JavaScript is (thanks to XPConnect)
<scc> Hmmm, interesting question
  I think the best answer to this question would come from John Bandhaur (jband@netscape.com) as the primary author of the XPConnect stuff
  however, speaking for perl
  I don't think much work would be needed at all
  perhaps less than 2 weeks worth
<chrisn> holy crap
<_AsA_> :)
<scc> Something to construct the appropriate data-structure to do the call throughs
  based on the XPT type information generated automatically by XPIDL
<waterson> but understand also that the DOM code does -not- use XPConnect
<scc> It could easily be done as a perl component
<chrisn> waterson: what do you mean?
<waterson> the DOM/JS glue predates XPConnect, and has not yet been converted to use it
  it uses a JavaScript-centric, generated layout of C++ code
  er, layer of C++ code
<scc> The plan is to convert the DOM to XPIDL, though, solving this dilemma
  I don't know the time frame for that conversion
<Seventh> how fast could be rated the XPConnect layer? how does threading impact speed (all over XPCOM in fact), mostly in relation to auto-proxied interfaces?
<scc> threading may well be the single biggest performance bottleneck in Mozilla
<Seventh> (inline Obj-C style dispatch would rate as "very fast" to me)
<waterson> *cough* WHAT?
<scc> dougt has already found and fixed major slowdowns in it
  There is no question that the XPConnect layer has a non-negligable cost
<waterson> scc: i disagree with both your statements
<scc> I couldn't say with certainty how it compares to a simple dispatch from C++, Objective-C, or Object Pascal, but it is certainly more costly
  waterson: go on
<Seventh> (C++ would rate as "extremely fast" and C as "instantaneous", BTW) :-)
<waterson> 1. threading has never shown up as a bottleneck in any profiling that i've done
  2. although there is a non-zero cost associated with method dispatch for XPC
  and it is large wrt. to say, native dispatch
  it is still dwarfed by other things
<scc> My answer is compatible with (and I agree with) 2
<waterson> (1) may be very dependent on platform
  e.g., i know you are a mac user
  there may be costs i haven't seen there.
<scc> As for 1, I defer to your knowledge ... waterson has done much more profiling than I have
  threading on the Mac _certainly_ sucks
  OK, next biggest bottleneck then: recursive layout?
<waterson> IMHO
<scc> I think dougt's recent work shows that threading could stand closer examination
<waterson> Seventh: relative to the overall computation in the app, thread switching on Win32 is negligible
<dougt> unix too.
<chrisn> has XPCOM's performance been impacted by its cross-platform nature (having to develop around the lowest-common-denominator of the platforms)?
<scc> hmmm
  I think the only thing that has impacted XPCOMs performance is bad code
  platform concerns are more likely to dominate NSPRs performance differences than XPCOMs
  The biggest impact on XPCOM from platform differences is compiler capabilities
  which has really only hit us in utility facilities like |nsCOMPtr| which push the limits of what some of the older compilers are willing to do
  Certainly, threading is an issue on the Mac
  As is the filesystem
  (but again, filesystem falls more under NSPR than XPCOM)
  other than that, however, I think XPCOM is fairly bipartisan
<simeon> What are XPCOM's impact on memory usage, as it compares to 4.x. Does it help memory management? are there downsides?
<scc> The primary downside to XPCOM may also be considered one of its strengths
  XPCOM enforces a reference-counting model for almost all objects
  This causes objects to live longer than they otherwise might have
  in other words, the app is `leakier'
  It helps in that most objects are now guaranteed to live _at_least_ as long as you want them to
  something waterson recently pointed out to me _was_not_ the case in 4.x
  But steady-state memory consumption ends up being greater
  and reference-counting is an ownership model
  it's an ownership modeling mechanism
  that lulls people into thinking they have an ownership model
  so developers fail to figure out in advance what the appropriate lifetime for any given object should be
  just because one object holds a pointer to another does not mean that other object should live as long as the first!
  To solve our memory problems, we need to make better use of weak references and think about the ownership model _before_ the fact
  should have said "reference-counting is _not_ an ownership model... it's an ..."
<jst_home> Has ther been any thoughts/plans for inventing distributed XPCOM (DXPCOM) yet, if not do you think this is something that will/should hapend within the scope of the mozilla project?
<scc> There has been talk
  however the scope of distributed COM is significantly bigger than COM
  There could be significant cross-process wins
  but cross-machine wins are questionable
  Currently, the main reason to use XPCOM is portability, and perhaps the ability to upgrade specific components independently
  we're using it most effectivly as a librarying technique
  No part of the project has yet called for a facility that could only be satisfied by a DXPCOM
  and until that happens, I doubt that we will internally be able to expend resources to do it
  but it could very well be an interesting outside project :-)
<Seventh> is anybody putting thoughts into going away from constructed progids and into component categories?
  if so, what is being done?
<scc> So far, we have been using the hierachical nature of our progids to serve the category role
  but categories is an often discussed topic
  AFAIK, no one is currently working on any deeper meaning for categories that what I just said
  It would make a good topic on netscape.public.mozilla.xpcom
<Seventh> is there a way to enumerate ProgIDs that implement a "category", or have two component implement the same thing, maybe differently? (like two 3D renderers in a game for example, one software and one hardware)
* scc blushes
<scc> I have no idea
  I don't know of one right off-hand
  the notion of category as it applies to progids is much more loosely defined that official component categories
  so things that do the same work, need to share progid prefixes
  I don't offhand know what facility is available for exploring registered progids with a given prefix
  but I'll look into it
* Seventh has his issues with the current progids scheme... :-)
<scc> :-)
<myk> scc: one of your first answers mentioned XPCOM exposing mozilla components to javascript. how cross-browser is that right now (i am assuming not at all) and how cross-browser is it likely to become? in other words, are there reasons for other browser manufacturers to support access to similar objects (like if such access became a standardized part of some generation of JavaScript)? basically, i'm wondering how much this internals exposure is useful to
<scc> Well, primarily, the current access is useful to people writing skins and interfaces in XUL
  until other browsers support XUL and a UI as configurable as ours, such code is not really cross _app_, though it is of course cross platform
  As mentioned previously, the scheme by which the DOM is made public in JavaScript is _currently_ a throwback
  since it is a standard API, I would expect it to be useful cross-app, though other apps need not implement their DOM using XPCOM
  and eventually the DOM access will be implmemented using XPIDL just like the rest of the app, but that change should be transparent to clients
  There is even a question about what access a normal web page might have to core app routines
  Not all the security issues have been worked out with this
  and for all I know, such considerations might end up crippling such access for anything other than DOM work ... except in `skins' and UI code
  so: DOM cross app; XUL, UI stuff, `skins' ... not yet
<chrisn> ok, any other questions tonight?
  Alright, I'd like to thank Scott Collins for showing up this evening
<myk> thanks Scott
<simeon> yay Scott!
<chrisn> we appreciate you stopping by
<scc> It was a pleasure ... don't hesitate to email me questions or post to n.p.m.xpcom