776382 - Remove Paris bindings .conf and add annotation to the .webidl files

Status: REOPENED

(Core :: DOM: Core & HTML, defect, P5)

Description

[Olli Pettay [:smaug][[e-mail]]]

Right now it is too hard to check what kind of method is required to implement
certain method defined in .webidl.
If all the annotations in .conf file would be moved to .webidl files, the setup would
look mot like the old style .idl setup and would be much more familiar to Gecko developers.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I don't think we want to move everything.  If there are specific annotations you want to move, file bugs on those.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

And the reason to not move everything is?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

What I want is easy to use (for Gecko developers) .webidl files.
Right now the setup is more complex that it needs to be.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

It is possible that for certain unusual webidl<->implementation mapping we need special config, but
for normal cases we really shouldn't need one.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So right now, what do we need the conf file for in typical cases?

1)  Concrete type stuff (classname, header).  We could try to come up with a naming
    convention here, if we wanted to, so it usually doesn't need to be specified.
2)  Weak return value annotations.  These might be pretty common.
3)  "Needs JS context" annotations.  These should be rare.  Are they?
4)  "No wrapper cache" annotations.  Again, probably rare...
5)  Castability annotations.
6)  Concreteness annotations.
7)  Prefability annotations (though this is temporary)
8)  Custom trace/finalization stuff
9)  The notflattened annotation; can we just make this true for all external things?
10) Binary name stuff
11) Registration stuff.  Only needed for test code.

Is that about it?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Boris Zbarsky (:bz) from comment #5)
> 2)  Weak return value annotations.  These might be pretty common.
You mean raw, non-addrefed?

> 3)  "Needs JS context" annotations.  These should be rare.  Are they?
Well, I don't think they are too rare, at least not in .idl files
http://mxr.mozilla.org/mozilla-central/search?string=implicit_jscontext&find=\.idl%24&findi=\.idl%24&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central


> 4)  "No wrapper cache" annotations.  Again, probably rare...
These could be rare, if paris bindings almost require wrappercache (I don't recall now in which
cases wrappercache isn't needed)


> 7)  Prefability annotations (though this is temporary)
Would be great have annotation to pref-on/off based on some particular pref.
[pref=dom.enable.foobarinterface]. But I guess you're talking about
generic whether-or-not to use paris bindings.

> 10) Binary name stuff
Already in .idl files. Why to move it to .conf?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

In other words, I think only some special cases should go to .conf (if there are any really such special cases). All the commonly used features should be implementable without adding anything to the .conf.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> You mean raw, non-addrefed?

Yes.

> at least not in .idl files

In WebIDL we pass in a JSContext automatically in many cases when it's needed (e.g. if the function takes or returns jsval or JSObject).  So annotations are only needed in cases when it's not obvious that the function needs a JSContext.

> Would be great have annotation to pref-on/off based on some particular pref.

We have this already on a per-method-or-property basis.  What are the use cases for a whole interface, other than the general "disable it because it's not ready" pref?

Comment 9

[Boris Zbarsky [:bzbarsky]]

From irc:

<roc> I think I favour having all annotations in the .webidl and using syntax or
      naming convention to separate out the implementation-specific annotations

Comment 10

[Boris Zbarsky [:bzbarsky]]

Peter, if we ditch most stuff from the conf file, can we just make codegen assume that no descriptor means an empty descriptor?  I think that should be sane...

Comment 11

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.