| <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 |
| However, | |
| the things we could are pretty cool | |
| for instance, | |
| we could directly support components that had been written for IE | |
| theoretically | |
| 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 |
| sorry | |
| <_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 |
| right | |
| <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 |