[patch] to Canvas2DRenderingContext DrawImage due to inherent flaw in python-xpcom
lkcl
this is a heads-up and a request for information and discussion
regarding XPCOM bindings on how to do optional arguments.
since starting to use python-xpcom here at europython three days ago
i've had one close call and one blocker issue when porting pyjamas-
desktop (a python widget toolkit that uses DOM technology to implement
the widget set) to XUL.
both of the issues were over the inaccessibility of optional
arguments. XMLHTTPRequest has OpenRequest but that is not made
available to python-xpcom thanks to the [noscript] option. open takes
two mandatory arguments and three additional optional ones (async,
username, password). _fortunately_, the default for the optional
async argument is "True", otherwise the XUL port of pyjamas-desktop
would have been completely screwed.
the latest one - DrawImage - is a complete blocker. in the IDL file,
there are zero arguments. in the implementation, it is assumed that
there will be a Javascript Context (which in python-xpcom there won't
be) and thus the optional arguments will be picked up from there
(which in python-xpcom they can't be).
thus i've created a patch which makes the first three arguments non-
optional, by adding them into the IDL file and thus python-xpcom and
all other XPCOM bindings can get at them.
so what are the solutions?
the typical simplest solution here is one which microsoft deploys when
using IDL files - simply create drawImage1 which takes 3 args,
drawImage2 which takes 5, and drawImage3 which takes 9. this policy
is something that microsoft has successfully deployed time and time
again for the past... what... 18 years since the introduction of DCE/
RPC into the very first version of the NT operating system (NT 3.1).
it's because IDL files are from DCE/RPC where the implementations were
at the time all c-based.
adding numbers to the function name is not pretty, but it works.
does anyone have any other suggestions?
l.
Boris Zbarsky
> there are zero arguments. in the implementation, it is assumed that
> there will be a Javascript Context (which in python-xpcom there won't
> be) and thus the optional arguments will be picked up from there
> (which in python-xpcom they can't be).
Yes. This was done more or less by design; part of the problem is that
the desired behavior of the function can't be expressed in xpidl. Or at
least couldn't be when the function was created. Maybe things have changed?
> thus i've created a patch which makes the first three arguments non-
> optional, by adding them into the IDL file and thus python-xpcom and
> all other XPCOM bindings can get at them.
I commented about that patch in the bug.
> the typical simplest solution here is one which microsoft deploys when
> using IDL files - simply create drawImage1 which takes 3 args,
> drawImage2 which takes 5, and drawImage3 which takes 9.
The problem is a limitation of xpidl and pyxcpom that would cause all
those methods to be exposed to web script if they're not marked
[noscript] (not acceptable) and not be exposed to pyxpcom if not marked
[noscript] (a stupid bug in pyxpcom, in my opinion).
> this policy is something that microsoft has successfully deployed time and time
> again for the past... what... 18 years since the introduction of DCE/
> RPC into the very first version of the NT operating system (NT 3.1).
Microsoft does not expose its IDL interfaces directly to web script.
> does anyone have any other suggestions?
Get enough WebIDL support implemented that this API can be expressed in
it in our code and start using WebIDL instead of xpidl?
-Boris
Benjamin Smedberg
> The problem is a limitation of xpidl and pyxcpom that would cause all
> those methods to be exposed to web script if they're not marked
> [noscript] (not acceptable) and not be exposed to pyxpcom if not marked
> [noscript] (a stupid bug in pyxpcom, in my opinion).
What's the bug? That pyxpcom refuses to script methods marked [noscript]?
That sounds like a really good idea to me: most of our method are marked
[noscript] because they don't actually follow the normal XPCOM rules, and
would cause leaks or other improper behavior if you did try to script them,
via XPCOM proxies, xpconnect, or pyxpcom.
--BDS
Boris Zbarsky
> What's the bug? That pyxpcom refuses to script methods marked [noscript]?
> That sounds like a really good idea to me: most of our method are marked
> [noscript] because they don't actually follow the normal XPCOM rules, and
> would cause leaks or other improper behavior if you did try to script them,
> via XPCOM proxies, xpconnect, or pyxpcom.
Well, maybe the problem then is that we overload [noscript] to both mean
[notxpcom] (which we have as a separate annotation, mind!) and to mean
"don't expose this to web js".
-Boris
Neil
> Well, maybe the problem then is that we overload [noscript] to both
> mean [notxpcom] (which we have as a separate annotation, mind!) and to
> mean "don't expose this to web js".
Isn't that because [notxpcom] actually means "return result directly
rather than using nsresult and outparam"?
--
Warning: May contain traces of nuts.
Boris Zbarsky
>> Well, maybe the problem then is that we overload [noscript] to both
>> mean [notxpcom] (which we have as a separate annotation, mind!) and to
>> mean "don't expose this to web js".
>
> Isn't that because [notxpcom] actually means "return result directly
> rather than using nsresult and outparam"?
Hmm. I thought we could flag individual arguments as [notxcom] to
indicate that they don't follow the XPCOM ownership rules. Maybe I was
mistaken.
In any case, this is a longstanding problem: we use [noscript] in ways
that are meant to only affect JS but also end up affecting pyxpcom and
java-xpcom...
-Boris
lkcl
> > the latest one - DrawImage - is a complete blocker. in the IDL file,
> > there are zero arguments. in the implementation, it is assumed that
> > there will be a Javascript Context (which in python-xpcom there won't
> > be) and thus the optional arguments will be picked up from there
> > (which in python-xpcom they can't be).
>
> Yes. This was done more or less by design; part of the problem is that
> the desired behavior of the function can't be expressed in xpidl. Or at
> least couldn't be when the function was created. Maybe things have changed?
>
> > thus i've created a patch which makes the first three arguments non-
> > optional, by adding them into the IDL file and thus python-xpcom and
> > all other XPCOM bindings can get at them.
>
> I commented about that patch in the bug.
>
> > the typical simplest solution here is one which microsoft deploys when
> > using IDL files - simply create drawImage1 which takes 3 args,
> > drawImage2 which takes 5, and drawImage3 which takes 9.
>
> The problem is a limitation of xpidl and pyxcpom that would cause all
> those methods to be exposed to web script if they're not marked
> [noscript] (not acceptable) and not be exposed to pyxpcom if not marked
> [noscript] (a stupid bug in pyxpcom, in my opinion).
>
> > this policy is something that microsoft has successfully deployed time and time
> > again for the past... what... 18 years since the introduction of DCE/
> > RPC into the very first version of the NT operating system (NT 3.1).
>
> Microsoft does not expose its IDL interfaces directly to web script.
ya - i figured (surmise) that the implementation of the web script
goes something like:
JSFunction()
{
JSContext ctx = getJScontext()
argc = ctx->argc
argv = ctx->argv
if argc == 5
return IDLisedInterfaceJSFunction1(argv[0], argv[1], ....
argv[4])
elif argc == 9
return IDLisedInterfaceJSFunction2(argv[0], argv[1], ....
argv[8])
}
pretty much for every single function, perhaps with some auto-
generator
or perhaps a base class which can deal with the "general" case where
the
web (JS) function matches exactly with the published IDL definition.
and then, COM (or, better DCOM in the MS case) can bind to the IDL
definitions, and JS is the "special strict" jobbie.
so, the lovely Visual Basic gets the function1, function2 etc. etc.
convention, and the lovely IE5-8 JS gets whatever MS decides that it
wants to call the W3C published spec function name, today.
i can see that you've taken this approach with e.g. OpenRequest in
XMLHttpRequest but then added [noscript] to make it unavailable, which
makes absolutely no sense!
the numbering approach is i believe a lot simpler than the meandering
that i can see going on, with noscript, optional, suggestions for
optional_argc and noxpcom.
i think that microsoft's approach, to treat JS as the first class
citizen and have that as the strict compliance naming-wise, and for
everything else to be "fair game", is just really really sensible.
step back and think about it for a second: not all languages (COM
bindings) have the concept of default values or even optional
arguments (c unless you want to get into a terrible mess with
varargs). not all languages can do function overloading (c, python).
therefore, sticking to the simplest approach - the one that's
originally c-based (DCOM is COM and is based on DCE/RPC, so the IDL
files revolve around c not c++) is just .... sensible.
and doing anything else - deviating from that original design - is
just going to get you into no end of trouble.
but, hey, i'm just a random free software developer - you're big
enough and ugly enough to work these things out for yourselves, or to
enjoy the pain of incompatible COM implementations across languages,
if that's what you're in to :)
i'm just glad it's hanging together enough for pyjamas-desktop to be
able to work at all. it took only 2 days to port pyjamas to python-
xpcom, and, staggeringly, the only thing i've found that won't work
(at all) is that SVG 2D Canvas context "DrawImage" function.
you should be absolutely dead proud of yourselves for that because
pyjamas is a pretty much unknown but very comprehensive DOM-using
project that squeezes absolutely every corner of its underlying DOM
api (in this case, xulrunner) until the pips squeak.
l.
lkcl
> > there are zero arguments. in the implementation, it is assumed that
> > there will be a Javascript Context (which in python-xpcom there won't
> > be) and thus the optional arguments will be picked up from there
> > (which in python-xpcom they can't be).
>
> Yes. This was done more or less by design; part of the problem is that
> the desired behavior of the function can't be expressed in xpidl. Or at
> least couldn't be when the function was created. Maybe things have changed?
sorry, i didn't read this bit first (meaning another post) -
apologies!
but, if you read that first, then this makes more sense:
1) if you have:
* DrawImage1 with 5 args and taking HTMLImageElement
* DrawImage2 with 5 args and taking HTMLCanvasElement
* DrawImage3 with 9 args and taking HTMLImageElement
* DrawImage4 with 9 args and taking HTMLCanvasElement
then you also have DrawImage() which takes zero args, and then you
get that to get its JS-based act together and call DI1,2,3 or 4, and
you make sure that DI1,2,3,4 are available to COM and not JS, and that
DrawImage is _not_ available to COM (cos it ain't gonna work) and _is_
available to JS, the problem is solved.
the issue at the moment is that you have a half-way-house that
satisfies only JS and pretty much absolutely no other language
bindings, and not even native c++. that's got to be bad.
2) to be absolutely honest, i really don't give a monkey's about 5
args or 9 args, what i think people do care about is the first 3
arguments. image, x and y. everything else - the clipping, the
resizing etc. etc. can be emulated (badly and with CPU cycles wasted)
another way.
if you cut people off from even those three arguments, they're
completely screwed, and all the work that's been put into SVG 2D
canvas is entirely useless.
but - leaving 2) aside for the bugreport, it's 1) that i wanted
people to consider as a generic approach - the simple way that's
worked for 18 years for microsoft. you've got [noscript] - if you add
[noxpcom] then it can be done:
[noxpcom] DrawImage
[noscript] DrawImage1
.....
.....
but it means that python-xpcom has to be updated to take [noscript]
into account, because at the moment it completely ignores it, which is
why i ran into difficulties not being able to access XMLHttpRequest's
[noscript] OpenRequest function.
l.