I don't know where XPConnect should be discussed, so I'm posting full
discussion to two groups (xpcom and jseng). Please, point me to correct
one.
On Wed, 10 Apr 2002 23:03:33 +0400, Brendan Eich wrote:
>>Hi!
>>I need to implement additional "standard" JavaScript class for making
>>http requests. SpiderMonkey will run as part of embedded browser and I
>>prefer to implement it inside libmozjs.so, without messing with
>>XPConnect. For class's users request will look as synchronous, however
>>user can specify timeout for it, so implementation should be
>>asynchronous.
>>
>>My plan is following: implement full blown StreamListener, then, inside
>>my JavaScript class method implementation:
>>
>> eventQService->PushThreadEventQueue(getter_AddRefs(mEventQueue)); ...
>> mChannel->AsyncOpen(mMyListener, nsnull); ... while (mRunEventLoop) {
>> mEventQueue->ProcessPendingEvents();
>> // timeout stuff using PR_IntervalNow()
>> }
>> ...
>> eventQService->PopThreadEventQueue(mEventQueue);
>>
>>The big question is: will such aproach work at all? If so, are there any
>>pitfalls which I should be aware of? For example, should I process all
>>pending events from current event queue before pushing my own? Any
>>useful sources from Mozilla's tree to look (so far I'm only found
>>nsXMLHttpRequest.cpp)? Docs?
>>
>>P.S. I'm not too skilful with threads :(
>>
> I don't think you should be avoiding XPConnect, or hacking "inside
> libmozjs.so". Especially if you're new to threads.
>
> Why not use XPCOM properly, and from the right library in the embedded
> browser?
>
> /be
I've considered using XPConnect, but rejected it for following reasons:
1. XPConnect is obviously way to go if you need to make already existing
XPCOM classes accessible from JavaScript. But in my case I don't have such
classes, therefore I would prefer to implement these additional
JavaScript classes as plain C++ classes: the more additional levels of
abstraction it is involved in implementation, the it is easier to make
something incorrectly. For example, if I'll make everything XPCOM, I'll
be forced to deal not only with possible GC leaks, but with refcounting
leaks too. It's all about keeping things simple.
2. Some of JavaScript classes I need to implement have complex methods
signatures and I can't change them: they are fixed by customer. For
example, there are methods which returns array of arrays, have optional
argument in the middle of arguments list and etc. It is not clear for me
how to handle such cases with XPConnect whereas it is quite clear how
to handle them with JavaScript API.
3. I have some classes to implement which doesn't need any other API
except JavaScript, so they fit quite nicely into libmozjs.so and I prefer
to keep all my hacks in one place.
And I'd like to have all things on it's places, but my projects is kind of
pilot, so the primary goal is to make things works.
So my question is: are there some technical benefits or "musts"
of XPConnect which I didn't take into account?
Thanks in advance.
Leonid.
