28833 - document tasks required to jettison idlc in favor of XPConnect

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Chris Waterson]

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.

Comment 1

[John Bandhauer]

er, "get rid of idlc".

Comment 2

[Chris Waterson]

right right. freudian slip.

Comment 3

[Chris Waterson]

Pasting in What We Know So Far...


Subject: XPConnect implemented DOM issues
Date: Fri, 18 Feb 2000 14:18:20 -0800
From: [e-mail] (John Bandhauer)
Organization: minions of mozilla
To: Chris Waterson <[e-mail]>,
     Vidur Apparao <[e-mail]>

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.

Comment 4

[Chris Waterson]

Subject: Re: XPConnect implemented DOM issues
Date: Fri, 18 Feb 2000 14:55:39 -0800
From: [e-mail] (Vidur Apparao)
To: John Bandhauer <[e-mail]>
CC: Chris Waterson <[e-mail]>, [e-mail]


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

Comment 5

[Chris Waterson]

Subject: Re: XPConnect implemented DOM issues
Date: Fri, 18 Feb 2000 16:12:32 -0800
From: [e-mail] (John Bandhauer)
Organization: minions of mozilla
To: [e-mail]
CC: Chris Waterson <[e-mail]>, [e-mail]

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.

Comment 6

[Chris Waterson]

Subject: Re: XPConnect implemented DOM issues
Date: Fri, 18 Feb 2000 17:08:42 -0800
From: [e-mail] (Vidur Apparao)
To: John Bandhauer <[e-mail]>
CC: Chris Waterson <[e-mail]>, [e-mail]


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.

Comment 7

[Chris Waterson]

http://www.mozilla.org/scriptable/agnostic.html

Comment 8

[Dawn Endico]

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

Comment 9

[Blake Ross]

*spam* changing qa contact from [e-mail] to me ([e-mail]) 
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 
[e-mail])

Anyways, sorry again for spam.  If you really get annoyed, I'm usually 
available in #mozilla on IRC for torture.

Comment 10

[Blake Ross]

QA assigning to doron to verify

Comment 11

[vidur (gone)]

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

Comment 12

[vidur (gone)]

jst will be driving this issue.

Comment 13

[David Ascher]

Nice to see activity here.  How can we help? 

--david ascher
  ActiveState

Comment 14

[Johnny Stenback (:jst)]

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?

Comment 15

[Johnny Stenback (:jst)]

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.

Comment 16

[Johnny Stenback (:jst)]

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.

Comment 17

[John Bandhauer]

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