This is a placeholder bug, reminding me to get off my arse and make a list of what needs to be done to get rid of XPConnect.

er, "get rid of idlc".

right right. freudian slip.

Pasting in What We Know So Far... Subject: XPConnect implemented DOM issues Date: Fri, 18 Feb 2000 14:18:20 -0800 From: jband@netscape.com (John Bandhauer) Organization: minions of mozilla To: Chris Waterson <waterson@netscape.com>, Vidur Apparao <vidur@netscape.com> An off the top of my head list of stuff to be dealt with in converting the DOM to use xpconnect... - An xpconnect interface flattening scheme is required for reflecting multiple DOM interfaces on JSObjects for cases where the interfaces are not part of an inheritance chain. This work is not done, but is not huge. XPConnect already handles reflecting methods from inherited interfaces. - presumably we need CDL to give xpconnect "interface set per component" info in order to do flattening. In fact, for a finite set of component types we can hard code this in some simpler scheme. - security is an issue that we haven't talked of... Right now we have a binary model for xpconnect: JS in content (presumably:) can't cross xpconnect boundaries. We would need to actually *use* the power of the nsIXPCSecurityManger to have a policy that allows calls across the selected DOM xpconnect interfaces and not others. More work in capsland. - There is a bug about not being able to uses xpconnect wrappers as __proto__ objects for other JSObjects. This has been a non-priority issue. Working this out would be required. - I *still* don't grok the DOM nsIScriptObjectOwner etc schemes well enough to speak intelligently about how to go about the conversion. - nsIXPCScriptable allows for a lot of customization behavior of the JSObject wrappers. I'm afraid we'd be writing a lot more of this code than we'd like. - I wonder if this will push xpconnect performance into the spotlight? - I can't gauge if an incremental conversion is feasible or not. Will DOMish things have trouble getting along if some are moved to xpconnect? - Are DOMland interfaces going to need serious changes to make this work? - FWIW, I have other things I'd *rather* do. But, if now really is the right time then I can jump into it. I'm sure I'm overlooking some important issues. John.

Subject: Re: XPConnect implemented DOM issues Date: Fri, 18 Feb 2000 14:55:39 -0800 From: vidur@netscape.com (Vidur Apparao) To: John Bandhauer <jband@netscape.com> CC: Chris Waterson <waterson@netscape.com>, joki@netscape.com A few off-the-cuff items that would need to be addressed to emulate things done in the glue code for 4.x compatibility: 1) Constructors, currently used for Image and Option classes. 2) Methods that take a variable number and type of arguments. 3) The "function" keyword for parameters - used to allow interface instances to be passed to the native method, but Javascript Function objects to be passed in by scripts. 4) Mapping from integer properties to the native Item() method and unknown string properties to the NamedItem() method when available. 5) IDL constants declared inside an interface reflected as class properties (e.g. Node.ELEMENT_NODE). 6) XPCOM return code to exception mapping - we construct a DOMException instance from which the DOM error code can be retrieved. My belief is that we'd have a hard time converting incrementally. It shouldn't be too hard to convert everything at one shot (the bulk of the interfaces should convert over without a fight), stripping out the edge cases and then incrementally adding in the edge cases. --Vidur

Subject: Re: XPConnect implemented DOM issues Date: Fri, 18 Feb 2000 16:12:32 -0800 From: jband@netscape.com (John Bandhauer) Organization: minions of mozilla To: vidur@netscape.com CC: Chris Waterson <waterson@netscape.com>, joki@netscape.com Good list. Lots of bits of work. Comments below. Vidur Apparao wrote: > > > A few off-the-cuff items that would need to be addressed to > emulate things done in the glue code for 4.x compatibility: > 1) Constructors, currently used for Image and Option classes. I have native code that implements constructors and allows building them from JS code via Components.Constructor. http://www.mozilla.org/scriptable/components_object.html#_Constructor http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/src/xpccomponents.cpp#1 310 They support 'instanceof' pretty much like any other JS constructor. This native constructor component can be exposed for creation via the component manager and named instances attached to 'window' for these types. > 2) Methods that take a variable number and type of arguments. nsIXPCNativeCallContext will help here. http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/idl/nsIXPConnect.idl#16 9 It allows you to declare a method in idl with optional trailing args (or no args at all) and then when the method gets called it can get at the JS argc and argv to grab (and manaually convert) additional args. > 3) The "function" keyword for parameters - used to allow > interface instances to be passed to the native method, but > Javascript Function objects to be passed in by scripts. Not sure what to do here. > 4) Mapping from integer properties to the native Item() method > and unknown string properties to the NamedItem() method when > available. I don't get this. > 5) IDL constants declared inside an interface reflected as > class properties (e.g. Node.ELEMENT_NODE). xpconnect has this except that they are reflected onto Components.interfaces.nsIFoo and onto instances of the object wrapper. We can add code to automatically reflect them onto the constructor objects (mentioned above) as appropriate and to new objects to manally reflect them otherwise. The later could perhaps just be aliases to the Components.interfaces.nsIFoo objects. > 6) XPCOM return code to exception mapping - we construct a > DOMException instance from which the DOM error code can be > retrieved. XPConnect has something like this but it builds an nsIXPCExcpetion object. Maybe we can add a flattened interface onto it for the view that DOM objects expect? John.

Subject: Re: XPConnect implemented DOM issues Date: Fri, 18 Feb 2000 17:08:42 -0800 From: vidur@netscape.com (Vidur Apparao) To: John Bandhauer <jband@netscape.com> CC: Chris Waterson <waterson@netscape.com>, joki@netscape.com Comments below. I'll start looking through source to see what else we might need. Another item that came to mind was: - The ability to return the JS value undefined from a method or attribute getter. We don't currently support this in idlc, but I plan to do it with a special nsresult value. Presumably this could be done with nsIXPCNativeCallContext for methods. John Bandhauer wrote: > Good list. Lots of bits of work. Comments below. > > Vidur Apparao wrote: > > > > > > A few off-the-cuff items that would need to be addressed to > > emulate things done in the glue code for 4.x compatibility: > > 1) Constructors, currently used for Image and Option classes. > > I have native code that implements constructors and allows > building them from JS code via Components.Constructor. > > http://www.mozilla.org/scriptable/components_object.html#_Constructor > > ttp://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/src/xpccomponents.cpp#13 10 > > They support 'instanceof' pretty much like any other JS > constructor. This native constructor component can be exposed for > creation via the component manager and named instances attached > to 'window' for these types. For this to work, there would need to be a way to have the Image and Option constructors be created automatically. Remember, it's not just the functionality that we need to emulate, it's the syntax as well. > > 2) Methods that take a variable number and type of arguments. > > nsIXPCNativeCallContext will help here. > http://lxr.mozilla.org/seamonkey/source > js/src/xpconnect/idl/nsIXPConnect.idl#169 > > It allows you to declare a method in idl with optional trailing > args (or no args at all) and then when the method gets called it > can get at the JS argc and argv to grab (and manaually convert) > additional args. This should work quite well. Presumably the implementation of the native methods could not carry over to other scripting languages since we'd be dealing with JS types. > > 3) The "function" keyword for parameters - used to allow > > interface instances to be passed to the native method, but > > Javascript Function objects to be passed in by scripts. > > Not sure what to do here. > > > 4) Mapping from integer properties to the native Item() method > > and unknown string properties to the NamedItem() method when > > available. > > I don't get this. The HTMLSelectElement interface has item() and namedItem() methods. The idlc glue maps any call to the class getter with an integer property (e.g. select[0]) to calls to the the item() method and calls with a string property that don't match any of the declared attributes to the namedItem() method. Simply, there needs to be a way for a native implementation to deal with properties that aren't explicitly declared as attributes in the IDL. > > 5) IDL constants declared inside an interface reflected as > > class properties (e.g. Node.ELEMENT_NODE). > > xpconnect has this except that they are reflected onto > Components.interfaces.nsIFoo and onto instances of the object > wrapper. We can add code to automatically reflect them onto the > constructor objects (mentioned above) as appropriate and to new > objects to manally reflect them otherwise. The later could > perhaps just be aliases to the Components.interfaces.nsIFoo > objects. Sounds like it could work. > > 6) XPCOM return code to exception mapping - we construct a > > DOMException instance from which the DOM error code can be > > retrieved. > > XPConnect has something like this but it builds an > nsIXPCExcpetion object. Maybe we can add a flattened interface > onto it for the view that DOM objects expect? Sounds like a possibility.

moving from architecture product to Browser. Architecture product is going away.

*spam* changing qa contact from nobody@mozilla.org to me (BlakeR1234@aol.com) on 121 open or resolved (but not verified) bugs. sorry for the spam everybody, but most of these bugs would just remain dormant and not checked by QA otherwise. I'm not sure how so many bugs have nobody as their QA contact, but I suspect this is the fault of some sort of bugzilla corruption that happened at some point (most of these bugs are in the 20000-26000 range, and I don't see where in the activity log that QA contact explicitly changed to nobody@mozilla.org) Anyways, sorry again for spam. If you really get annoyed, I'm usually available in #mozilla on IRC for torture.

QA assigning to doron to verify

We're going to take this on now. So reopening the bug.

jst will be driving this issue.

Nice to see activity here. How can we help? --david ascher ActiveState

Nice to know there's more interest in getting this done, right now we're just starting to think about what needs to be done before we can make this switchover, there's a lot of issues to be resolved, more updates as things progress... I just thought of one more thing we need to think about here, how are we gonna deal with the various 'onxxx' properties in the DOM? Currently they're dealt with in nsGenericElement::SetProperty(), among other places, if we continue to do the same we need to have every element implement nsIXPCScriptable which we wanted to avoid to save a vtable per element object. I don't currently see a way around this. The properties are also dealth with through the interface nsIDOMWindowEventOwner, can we continue to use that with XPConnect? That interface uses jsval arguments, can we continue to use those in the new world?

It looks like we can solve the onxxx properties with an interface containing all the different onxxx attributes as nsISupport attributes and XPConnect can wrap the finctions as needed, have a look at http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#470 for how Vidur did something very similar in XML extras.

Setting milestone to mozilla1.0 to keep this tracking bug off my immediate bug radar, I am currntly working on all the issues listed here.

hey, nothing left to document right? the deed is done.