Dan Lange wrote:
<snip>
> I can not use separate proxies for the Service and the DataSource. When I
> try to proxy the DataSource, the Proxy Manager crashes, because it uses
> GetAddRef, which recognizes that the Proxy Manager is running in my thread,
> while the DataSource can only be used in the UI thread, and throws a
> threadsafe exception.
> If I try to proxy the proxy manager, so that it too is running in the UI
> thread, it just laughs at me an crashes.
>
> So, I have to put both the Service and the DataSource under the same Proxy.
> Which I can only do by building my own XPCOM component that manipulates both
> of them; and then proxying my component.
If I understand so far, you want to create your component that runs
under the UI thread and talk to it via proxy. Yes? No?
> At this point, things get a little murky, because I can not find any
> documentation about either:
> a) How someone outside Mozilla can build an XPCOM component that will run in
> Mozilla.
Here's the shortened version:
First, create an IDL file that describes the interface(s) used by your
component.
Second, compile the IDL file with the xpidl compiler - it will produce
a C++ header file where the interface is a C++ class with virtual
methods. It will also produce a commented-out stub implementation.
Third, take the stub implementation and add your code to it.
Fourth, add some boilerplate code for the module definition and you're done!
> b) How to build an XPCOM component such that it is proxyable.
I recall seeing some code that created some components by proxy
(for LDAP support and in JavaScript no less). It would make a great
example but I can't seem to find it just now.
AFAIK, you have two options with the proxy manager - synchronous and
asynchronous. The proxied component's thread basically runs a message
loop. Proxied calls become messages processed one-at-a-time in the
thread's message loop. Your thread can use the proxy manager to either
post a message and ignore any possible error/result values or wait for
the other thread to respond with an nsResult and output params (if any).
> As near as I can make out, the proxy code relies on the .xpt file which is
> generated by the idl compiler. It uses this file to determine the proxy's
> interfaces. There is a file named xpti.dat that is used to determine which
> xpt files are loaded.
Its more of a directory of available components.
> This complete list of all XPCOM interfaces is
> generated by Mozilla, and I really shouldn't be changing it, especially
> not if I want to be compatible with multiple Mozilla versions.
The component manager generates this file by examining the XPT
files of all the components in the components folder.
> So, I can't create a proxyable XPCOM component unless it is part
> of core Mozilla.
Not true - you can drop in new components (both JS and shared library
files) at any time - tell the component manager to auto-register and
the new addition becomes available. Fire up mozilla, go to mozdev.org
and download some of the XUL based games - some of these register
their own components.
> Therefore, I can't access RDF from a non-UI thread.
> Therefore, I can't build my java to RDF API.
>
> If my chain of reasoning has gone astray at any point, please let
> me know.
> Thanks,
> -- Dan
You can add new components to mozilla at any time (I'm not sure
about removal).
Hope that helps.
Rick
