Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-14 Thread luoyonggang 


It's seems they are all dead.
在 2016/1/14 20:02, Philip Chee  写道:

   On 04/01/2016 20:13, 罗勇刚(Yonggang Luo)  wrote:

On Mon, Jan 4, 2016 at 7:22 PM, Bobby Holley  wrote:


If you're forking mozilla-central, that shouldn't be a problem, right?


I am asking for some help, seeking for problems when I was trying to
implement XPCOM  connect with js-ctypes.
So far, the garbage collection would be the biggest problem.
Even though WebIDL has it's own advantages, but XPCOM are more
language-neutral.

   Have you looked at libraries such as SpiderApe or libjspp?
   Phil


- Send from WPS Mail -
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-14 Thread Philip Chee 
On 04/01/2016 20:13, 罗勇刚(Yonggang Luo)  wrote:
> On Mon, Jan 4, 2016 at 7:22 PM, Bobby Holley  wrote:
> 
>> If you're forking mozilla-central, that shouldn't be a problem, right?
>>
> I am asking for some help, seeking for problems when I was trying to
> implement XPCOM  connect with js-ctypes.
> So far, the garbage collection would be the biggest problem.
> Even though WebIDL has it's own advantages, but XPCOM are more
> language-neutral.

Have you looked at libraries such as SpiderApe or libjspp?

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Bobby Holley 
If you're forking mozilla-central, that shouldn't be a problem, right?
On Jan 4, 2016 12:46 AM, "罗勇刚(Yonggang Luo)"  wrote:

> Well, cause that's not possible to implement APIs in webidl in the
> external dll with the xul
>
> On Mon, Jan 4, 2016 at 3:55 PM, Bobby Holley 
> wrote:
>
>> Why not use webidl to expose the apis you want in workers?
>> On Jan 3, 2016 8:08 PM, "罗勇刚(Yonggang Luo)" 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 4, 2016 at 6:38 AM, Bobby Holley 
>>> wrote:
>>>
 As XPConnect module owner, I'd like to get it in record that we will
 almost
 certainly not take this or any support code for it (i.e. code in
 js-ctypes)
 in mozilla-central.

 Well, I was already have a modified version of mozilla-central, if the
>>> upstream is not possible, then I just need to maintain the fork and can not
>>> upstream the code.
>>>
 On Sun, Jan 3, 2016 at 11:46 AM, Joshua Cranmer  
 wrote:

 > On 1/3/2016 10:24 AM, 罗勇刚(Yonggang Luo) wrote:
 >
 >> So that we could be able to access xpcom in worker.
 >> And we could be able  to implement thunderbird new msg protocol in
 pure
 >> javascript
 >>
 >
 > I will point out that Thunderbird developers are already looking into
 > replacing the xpcom use of message protocols, so if that is the
 primary
 > goal, then you are wasting your time, I am afraid.
 >
 > I will also point out that both JavaScript and C++ have moved on from
 the
 > time xpconnect was developed to the point that use of xpconnect
 requires
 > designing APIs that are uncomfortable to use from C++ or JavaScript
 (or
 > even both!), so it is a much better investment of time to move APIs to
 > newer paradigms than it is to try to develop a system that almost no
 one
 > really understands.
 >
 > --
 > Joshua Cranmer
 > Thunderbird and DXR developer
 > Source code archæologist
 >
 >
 > ___
 > dev-platform mailing list
 > dev-platform@lists.mozilla.org
 > https://lists.mozilla.org/listinfo/dev-platform
 >
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

>>>
>>>
>>>
>>> --
>>>  此致
>>> 礼
>>> 罗勇刚
>>> Yours
>>> sincerely,
>>> Yonggang Luo
>>>
>>
>
>
> --
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Yonggang Luo 
On Mon, Jan 4, 2016 at 7:22 PM, Bobby Holley  wrote:

> If you're forking mozilla-central, that shouldn't be a problem, right?
>
I am asking for some help, seeking for problems when I was trying to
implement XPCOM  connect with js-ctypes.
So far, the garbage collection would be the biggest problem.
Even though WebIDL has it's own advantages, but XPCOM are more
language-neutral.

On Jan 4, 2016 12:46 AM, "罗勇刚(Yonggang Luo)"  wrote:
>
>> Well, cause that's not possible to implement APIs in webidl in the
>> external dll with the xul
>>
>> On Mon, Jan 4, 2016 at 3:55 PM, Bobby Holley 
>> wrote:
>>
>>> Why not use webidl to expose the apis you want in workers?
>>> On Jan 3, 2016 8:08 PM, "罗勇刚(Yonggang Luo)" 
>>> wrote:
>>>


 On Mon, Jan 4, 2016 at 6:38 AM, Bobby Holley 
 wrote:

> As XPConnect module owner, I'd like to get it in record that we will
> almost
> certainly not take this or any support code for it (i.e. code in
> js-ctypes)
> in mozilla-central.
>
> Well, I was already have a modified version of mozilla-central, if the
 upstream is not possible, then I just need to maintain the fork and can not
 upstream the code.

> On Sun, Jan 3, 2016 at 11:46 AM, Joshua Cranmer  <
> pidgeo...@gmail.com>
> wrote:
>
> > On 1/3/2016 10:24 AM, 罗勇刚(Yonggang Luo) wrote:
> >
> >> So that we could be able to access xpcom in worker.
> >> And we could be able  to implement thunderbird new msg protocol in
> pure
> >> javascript
> >>
> >
> > I will point out that Thunderbird developers are already looking into
> > replacing the xpcom use of message protocols, so if that is the
> primary
> > goal, then you are wasting your time, I am afraid.
> >
> > I will also point out that both JavaScript and C++ have moved on
> from the
> > time xpconnect was developed to the point that use of xpconnect
> requires
> > designing APIs that are uncomfortable to use from C++ or JavaScript
> (or
> > even both!), so it is a much better investment of time to move APIs
> to
> > newer paradigms than it is to try to develop a system that almost no
> one
> > really understands.
> >
> > --
> > Joshua Cranmer
> > Thunderbird and DXR developer
> > Source code archæologist
> >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



 --
  此致
 礼
 罗勇刚
 Yours
 sincerely,
 Yonggang Luo

>>>
>>
>>
>> --
>>  此致
>> 礼
>> 罗勇刚
>> Yours
>> sincerely,
>> Yonggang Luo
>>
>


-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Yonggang Luo 
Well, cause that's not possible to implement APIs in webidl in the external
dll with the xul

On Mon, Jan 4, 2016 at 3:55 PM, Bobby Holley  wrote:

> Why not use webidl to expose the apis you want in workers?
> On Jan 3, 2016 8:08 PM, "罗勇刚(Yonggang Luo)"  wrote:
>
>>
>>
>> On Mon, Jan 4, 2016 at 6:38 AM, Bobby Holley 
>> wrote:
>>
>>> As XPConnect module owner, I'd like to get it in record that we will
>>> almost
>>> certainly not take this or any support code for it (i.e. code in
>>> js-ctypes)
>>> in mozilla-central.
>>>
>>> Well, I was already have a modified version of mozilla-central, if the
>> upstream is not possible, then I just need to maintain the fork and can not
>> upstream the code.
>>
>>> On Sun, Jan 3, 2016 at 11:46 AM, Joshua Cranmer  
>>> wrote:
>>>
>>> > On 1/3/2016 10:24 AM, 罗勇刚(Yonggang Luo) wrote:
>>> >
>>> >> So that we could be able to access xpcom in worker.
>>> >> And we could be able  to implement thunderbird new msg protocol in
>>> pure
>>> >> javascript
>>> >>
>>> >
>>> > I will point out that Thunderbird developers are already looking into
>>> > replacing the xpcom use of message protocols, so if that is the primary
>>> > goal, then you are wasting your time, I am afraid.
>>> >
>>> > I will also point out that both JavaScript and C++ have moved on from
>>> the
>>> > time xpconnect was developed to the point that use of xpconnect
>>> requires
>>> > designing APIs that are uncomfortable to use from C++ or JavaScript (or
>>> > even both!), so it is a much better investment of time to move APIs to
>>> > newer paradigms than it is to try to develop a system that almost no
>>> one
>>> > really understands.
>>> >
>>> > --
>>> > Joshua Cranmer
>>> > Thunderbird and DXR developer
>>> > Source code archæologist
>>> >
>>> >
>>> > ___
>>> > dev-platform mailing list
>>> > dev-platform@lists.mozilla.org
>>> > https://lists.mozilla.org/listinfo/dev-platform
>>> >
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>>
>> --
>>  此致
>> 礼
>> 罗勇刚
>> Yours
>> sincerely,
>> Yonggang Luo
>>
>


-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread David Rajchenbach-Teller 
Yes, I mostly meant XPConnect.

On 04/01/16 14:36, smaug wrote:
> On 01/03/2016 06:35 PM, David Rajchenbach-Teller wrote:
>> Accessing XPCOM in a worker will most likely break the garbage-collector
>> in novel and interesting ways,
> 
> Why would it? Our workers are full of xpcom stuff.
> One needs to be careful what to touch sure, and deal with CC and GC
> handling like in the main thread.
> 
> But perhaps you meant xpconnect, not xpcom.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread smaug 

On 01/03/2016 06:55 PM, David Rajchenbach-Teller wrote:

Well, XPConnect is designed for the main thread, and many of the things
it does assume that everything takes place on the main thread.

An example, from the topic of my head: whenever objects cross between
JavaScript and C++ through XPConnect, they need to be retained in
hashtables to preserve unicity, etc. For performance reasons, these
hashtables are not protected against concurrent access.


Indeed. Which is why he is thinking to re-implement xpconnect for workers using 
js-ctypes, no?
(personally I'd try to avoid xpconnect as much as possible and rather try to 
figure out how to make
 the webidl bindings usable for whatever use case we're talking about here.)



Another example: JavaScript objects can point towards C++ objects and
vice-versa. The garbage-collector (well, the cycle-collector) needs to
walk the graph in specific ways to get rid of possible cycles that
involve both C++ and JS.

This happens in workers too.



The worker's implementation of the
cycle-collector is much simpler (and quite different) than the main
thread's,

Not really. Cycle collector is exactly the same (CycleCollectorRuntime is a bit 
more complicated in main thread)...



since it doesn't need to handle XPConnect.

...XPConnect just adds couple of extra js value containers to trace. Not at all 
that different
to JSHolder hashtable which is used also in workers.
XPCWrappedJS is possibly the weirdest part of xpconnect from CC/GC point of 
view, given that it
implements also weakreference handling.


But anyhow, I would certainly try to avoid any new xpconnect usage and try to 
figure out how to utilize
webidl. Webidl can express APIs in more JS-friendly way and in Gecko case also 
the C++ side is way simpler
(and faster) than implementing idl interfaces in C++.


-Olli



> Mixing both

accidentally can lead to unpredictable results.

Oh, and XPConnect pointers can simply not be dereferenced from worker
threads. Attempting to do so will crash libxul by design to avoid accidents.

etc.

Cheers,
  David

On 03/01/16 17:45, 罗勇刚(Yonggang Luo)  wrote:



On Mon, Jan 4, 2016 at 12:35 AM, David Rajchenbach-Teller
> wrote:

 Accessing XPCOM in a worker will most likely break the garbage-collector
 in novel and interesting ways, so I don't suggest heading in that
 direction.

I'd like to hear more information about that,
For example, if I setting a finalize for  each XPCOM instance
Object(javascript), when the Object's is GCed, then I release
the xpcom instance, is that would not break the garbage-collector?
Or we have other problems about garbage-collector, I am interested in that.



 Cheers,
  David

 On 03/01/16 17:24, 罗勇刚(Yonggang Luo)  wrote:
 > So that we could be able to access xpcom in worker.
 > And we could be able  to implement thunderbird new msg protocol in
 pure
 > javascript
 >
 > On Sun, Jan 3, 2016 at 11:09 PM, Josh Matthews
 >
 > wrote:
 >
 >> What is the motivation for this work?

 >>
 >> ___
 >> dev-platform mailing list
 >> dev-platform@lists.mozilla.org
 
 >> https://lists.mozilla.org/listinfo/dev-platform
 >>
 >
 >
 >




--
  此致
礼
罗勇刚
Yours
 sincerely,
Yonggang Luo


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread smaug 

On 01/03/2016 06:35 PM, David Rajchenbach-Teller wrote:

Accessing XPCOM in a worker will most likely break the garbage-collector
in novel and interesting ways,


Why would it? Our workers are full of xpcom stuff.
One needs to be careful what to touch sure, and deal with CC and GC handling 
like in the main thread.

But perhaps you meant xpconnect, not xpcom.



so I don't suggest heading in that direction.

Cheers,
  David

On 03/01/16 17:24, 罗勇刚(Yonggang Luo)  wrote:

So that we could be able to access xpcom in worker.
And we could be able  to implement thunderbird new msg protocol in pure
javascript

On Sun, Jan 3, 2016 at 11:09 PM, Josh Matthews 
wrote:


What is the motivation for this work?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform







___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Yonggang Luo 
On Mon, Jan 4, 2016 at 9:53 PM, smaug  wrote:

> On 01/03/2016 06:55 PM, David Rajchenbach-Teller wrote:
>
>> Well, XPConnect is designed for the main thread, and many of the things
>> it does assume that everything takes place on the main thread.
>>
>> An example, from the topic of my head: whenever objects cross between
>> JavaScript and C++ through XPConnect, they need to be retained in
>> hashtables to preserve unicity, etc. For performance reasons, these
>> hashtables are not protected against concurrent access.
>>
>> Indeed. Which is why he is thinking to re-implement xpconnect for workers
> using js-ctypes, no?
> (personally I'd try to avoid xpconnect as much as possible and rather try
> to figure out how to make
>  the webidl bindings usable for whatever use case we're talking about
> here.)
>
>
> Another example: JavaScript objects can point towards C++ objects and
>> vice-versa. The garbage-collector (well, the cycle-collector) needs to
>> walk the graph in specific ways to get rid of possible cycles that
>> involve both C++ and JS.
>>
> This happens in workers too.
>
>
> The worker's implementation of the
>> cycle-collector is much simpler (and quite different) than the main
>> thread's,
>>
> Not really. Cycle collector is exactly the same (CycleCollectorRuntime is
> a bit more complicated in main thread)...

So, the a bit more complicated part are used to dealing with the XPConnect
things?
I am trying to figure out a way that support

>
>
>
> since it doesn't need to handle XPConnect.
>>
> ...XPConnect just adds couple of extra js value containers to trace. Not
> at all that different
> to JSHolder hashtable which is used also in workers.
> XPCWrappedJS is possibly the weirdest part of xpconnect from CC/GC point
> of view, given that it
> implements also weakreference handling.
>
>
> But anyhow, I would certainly try to avoid any new xpconnect usage and try
> to figure out how to utilize
> webidl. Webidl can express APIs in more JS-friendly way and in Gecko case
> also the C++ side is way simpler
> (and faster) than implementing idl interfaces in C++.
>
1、I was not trying implement new things in xpcom, our company(Kingsoft) are
maintaining a fork of thunderbird, and at the current time
We have to re-use existing XPCOM components that already exists in  the
thunderbid gecko world, beyond pure html
things, there is too much things we have to re-use(xpcom things), and we
are facing  performance problems,
the mork-db and the mime-parse, they are all working in synchronous way, so
I have to figure out a way to calling these components
in a worker directly, so that they would not cause UI-lag in main-thread.
That's all the reason why I was trying to re-implement XPConnect with
js-ctypes. So  that I can calling
the exist components in the worker. And free the main-thread.

2、Besides these reason, another important reason, I didn't see any
way(example) to use WebIDL without building
xul.dll, maintain the xul.dll is a big burden for small teams (for us,
about 8 developers), so even if we trying to implement WebIDL things,
we need a way to building WebIDL components independently, at the current
time, I didn't see any possibilities.

3、 There is an advantage of XPCOM, WebIDL seems merely for Javascript, but
XPCOM seems more language-neutral, we could be able to
use xpcom in Java/Python and other languages, that's looks like a advantage
of XPCOM.

-Olli
>
>
>
> > Mixing both
>
>> accidentally can lead to unpredictable results.
>>
>> Oh, and XPConnect pointers can simply not be dereferenced from worker
>> threads. Attempting to do so will crash libxul by design to avoid
>> accidents.
>>
>> etc.
>>
>> Cheers,
>>   David
>>
>> On 03/01/16 17:45, 罗勇刚(Yonggang Luo)  wrote:
>>
>>>
>>>
>>> On Mon, Jan 4, 2016 at 12:35 AM, David Rajchenbach-Teller
>>> > wrote:
>>>
>>>  Accessing XPCOM in a worker will most likely break the
>>> garbage-collector
>>>  in novel and interesting ways, so I don't suggest heading in that
>>>  direction.
>>>
>>> I'd like to hear more information about that,
>>> For example, if I setting a finalize for  each XPCOM instance
>>> Object(javascript), when the Object's is GCed, then I release
>>> the xpcom instance, is that would not break the garbage-collector?
>>> Or we have other problems about garbage-collector, I am interested in
>>> that.
>>>
>>>
>>>
>>>  Cheers,
>>>   David
>>>
>>>  On 03/01/16 17:24, 罗勇刚(Yonggang Luo)  wrote:
>>>  > So that we could be able to access xpcom in worker.
>>>  > And we could be able  to implement thunderbird new msg protocol in
>>>  pure
>>>  > javascript
>>>  >
>>>  > On Sun, Jan 3, 2016 at 11:09 PM, Josh Matthews
>>>  >
>>>  > wrote:
>>>  >
>>>  >> What is the motivation for this work?
>>>
>>>  >>
>>>  >> ___
>>>  >>

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Joshua Cranmer  

On 1/4/2016 9:24 AM, 罗勇刚(Yonggang Luo) wrote:

1、I was not trying implement new things in xpcom, our company(Kingsoft) are
maintaining a fork of thunderbird, and at the current time
We have to re-use existing XPCOM components that already exists in  the
thunderbid gecko world, beyond pure html
things, there is too much things we have to re-use(xpcom things), and we
are facing  performance problems,
the mork-db and the mime-parse, they are all working in synchronous way, so
I have to figure out a way to calling these components
in a worker directly, so that they would not cause UI-lag in main-thread.
That's all the reason why I was trying to re-implement XPConnect with
js-ctypes. So  that I can calling
the exist components in the worker. And free the main-thread.


Mork, by design, can't be used off main-thread. So even if you're trying 
to subvert it by using JS-ctypes and etc., it's not going to work very 
well, let alone the problems you have with trying to maintain a 
pseudo-reimplementation of xpconnect.

3、 There is an advantage of XPCOM, WebIDL seems merely for Javascript, but
XPCOM seems more language-neutral, we could be able to
use xpcom in Java/Python and other languages, that's looks like a advantage
of XPCOM.
XPIDL is effectively a fork of an old version of IDL. Its interfaces are 
incapable of cleanly representing union types or array types very well, 
something that WebIDL does far better, as WebIDL is partly a fork of a 
newer version of IDL. I believe there already exists WebIDL bindings for 
C++, JS, and Rust, and extending it to Java or Python would not be a 
challenging task. The only complexity is that the WebIDL bindings does 
not use a grand-central dispatch mechanism like XPConnect, but that 
merely means that adding new bindings requires writing a code generator 
and feeding all the interfaces through it instead of implementing 
several customized dispatch mechanisms. Not that PyXPCOM or JavaXPCOM 
have worked for the past several years.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Yonggang Luo 
On Mon, Jan 4, 2016 at 11:37 PM, Joshua Cranmer  
wrote:

> On 1/4/2016 9:24 AM, 罗勇刚(Yonggang Luo) wrote:
>
>> 1、I was not trying implement new things in xpcom, our company(Kingsoft)
>> are
>> maintaining a fork of thunderbird, and at the current time
>> We have to re-use existing XPCOM components that already exists in  the
>> thunderbid gecko world, beyond pure html
>> things, there is too much things we have to re-use(xpcom things), and we
>> are facing  performance problems,
>> the mork-db and the mime-parse, they are all working in synchronous way,
>> so
>> I have to figure out a way to calling these components
>> in a worker directly, so that they would not cause UI-lag in main-thread.
>> That's all the reason why I was trying to re-implement XPConnect with
>> js-ctypes. So  that I can calling
>> the exist components in the worker. And free the main-thread.
>>
>
> Mork, by design, can't be used off main-thread. So even if you're trying
> to subvert it by using JS-ctypes and etc., it's not going to work very
> well, let alone the problems you have with trying to maintain a
> pseudo-reimplementation of xpconnect.
>
>> 3、 There is an advantage of XPCOM, WebIDL seems merely for Javascript, but
>> XPCOM seems more language-neutral, we could be able to
>> use xpcom in Java/Python and other languages, that's looks like a
>> advantage
>> of XPCOM.
>>
> XPIDL is effectively a fork of an old version of IDL. Its interfaces are
> incapable of cleanly representing union types or array types very well,
> something that WebIDL does far better, as WebIDL is partly a fork of a
> newer version of IDL. I believe there already exists WebIDL bindings for
> C++, JS, and Rust, and extending it to Java or Python would not be a
> challenging task. The only complexity is that the WebIDL bindings does not
> use a grand-central dispatch mechanism like XPConnect, but that merely
> means that adding new bindings requires writing a code generator and
> feeding all the interfaces through it instead of implementing several
> customized dispatch mechanisms. Not that PyXPCOM or JavaXPCOM have worked
> for the past several years.

The core issue is WebIDL is not usable in non-gecko code yet, I didn't see
any example in thunderbird source tree, but I see lots of XPCOM codes. So I
do not have any clue how to using WebIDL in thunderbird world

>
>
> --
> Joshua Cranmer
> Thunderbird and DXR developer
> Source code archæologist
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Bobby Holley 
On Mon, Jan 4, 2016 at 10:01 AM, 罗勇刚(Yonggang Luo) 
wrote:

>
>
> On Tue, Jan 5, 2016 at 1:33 AM, Bobby Holley 
> wrote:
>
>> On Mon, Jan 4, 2016 at 7:57 AM, 罗勇刚(Yonggang Luo) 
>> wrote:
>>
>>> On Mon, Jan 4, 2016 at 11:37 PM, Joshua Cranmer  
>>> wrote:
>>>
>>> > On 1/4/2016 9:24 AM, 罗勇刚(Yonggang Luo) wrote:
>>> >
>>> >> 1、I was not trying implement new things in xpcom, our
>>> company(Kingsoft)
>>> >> are
>>> >> maintaining a fork of thunderbird, and at the current time
>>> >> We have to re-use existing XPCOM components that already exists in
>>> the
>>> >> thunderbid gecko world, beyond pure html
>>> >> things, there is too much things we have to re-use(xpcom things), and
>>> we
>>> >> are facing  performance problems,
>>> >> the mork-db and the mime-parse, they are all working in synchronous
>>> way,
>>> >> so
>>> >> I have to figure out a way to calling these components
>>> >> in a worker directly, so that they would not cause UI-lag in
>>> main-thread.
>>> >> That's all the reason why I was trying to re-implement XPConnect with
>>> >> js-ctypes. So  that I can calling
>>> >> the exist components in the worker. And free the main-thread.
>>> >>
>>> >
>>> > Mork, by design, can't be used off main-thread. So even if you're
>>> trying
>>> > to subvert it by using JS-ctypes and etc., it's not going to work very
>>> > well, let alone the problems you have with trying to maintain a
>>> > pseudo-reimplementation of xpconnect.
>>> >
>>> >> 3、 There is an advantage of XPCOM, WebIDL seems merely for
>>> Javascript, but
>>> >> XPCOM seems more language-neutral, we could be able to
>>> >> use xpcom in Java/Python and other languages, that's looks like a
>>> >> advantage
>>> >> of XPCOM.
>>> >>
>>> > XPIDL is effectively a fork of an old version of IDL. Its interfaces
>>> are
>>> > incapable of cleanly representing union types or array types very well,
>>> > something that WebIDL does far better, as WebIDL is partly a fork of a
>>> > newer version of IDL. I believe there already exists WebIDL bindings
>>> for
>>> > C++, JS, and Rust, and extending it to Java or Python would not be a
>>> > challenging task. The only complexity is that the WebIDL bindings does
>>> not
>>> > use a grand-central dispatch mechanism like XPConnect, but that merely
>>> > means that adding new bindings requires writing a code generator and
>>> > feeding all the interfaces through it instead of implementing several
>>> > customized dispatch mechanisms. Not that PyXPCOM or JavaXPCOM have
>>> worked
>>> > for the past several years.
>>>
>>> The core issue is WebIDL is not usable in non-gecko code yet, I didn't
>>> see
>>> any example in thunderbird source tree, but I see lots of XPCOM codes.
>>> So I
>>> do not have any clue how to using WebIDL in thunderbird world
>>>
>>
>> You would certainly need to blaze this trail. But it's certainly possible
>> (given that you're willing to fork mozilla-central), and I guarantee it
>> will be more tractable than rewriting XPConnect with JS-CTypes.
>>
>>
> In fact, the only reason to use WebIDL is to getting javascript to using
> some native code, but the situation is I have no need to do that, all the
> new code we've writing down are in pure Javascript, if we have the willing
> to implement something with WebIDL, for example, the IMAP protocol, then
> we would choose the pure javascript to do that, like the jsmime does.
> The reason to rewriting XPConnect with JS-CTypes is not to use XPCOM  to
> implement new things, but to re-use exist things.
>

Are you talking about calling existing native code from JS? You can do that
with WebIDL by writing binding entry points for the classes you want.

If you're talking about impersonating arbitrary XPCOM components with
JS-implemented code...good luck doing that with anything other than
XPConnect. ;-)


> Besides the mork database are only capable to running in main-thread, is
> that possible to running the libmime in the worker?
> Cause the libmime is really CPU intensive, I've seen it occupied 100%
> usage of CPU, if that could be able to off main-thread, then that's would
> be a great performance improvement.
>
>>
>>> >
>>> >
>>> > --
>>> > Joshua Cranmer
>>> > Thunderbird and DXR developer
>>> > Source code archæologist
>>> >
>>> > ___
>>> > dev-platform mailing list
>>> > dev-platform@lists.mozilla.org
>>> > https://lists.mozilla.org/listinfo/dev-platform
>>> >
>>>
>>>
>>>
>>> --
>>>  此致
>>> 礼
>>> 罗勇刚
>>> Yours
>>> sincerely,
>>> Yonggang Luo
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>
>
> --
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Bobby Holley 
On Mon, Jan 4, 2016 at 7:57 AM, 罗勇刚(Yonggang Luo) 
wrote:

> On Mon, Jan 4, 2016 at 11:37 PM, Joshua Cranmer  
> wrote:
>
> > On 1/4/2016 9:24 AM, 罗勇刚(Yonggang Luo) wrote:
> >
> >> 1、I was not trying implement new things in xpcom, our company(Kingsoft)
> >> are
> >> maintaining a fork of thunderbird, and at the current time
> >> We have to re-use existing XPCOM components that already exists in  the
> >> thunderbid gecko world, beyond pure html
> >> things, there is too much things we have to re-use(xpcom things), and we
> >> are facing  performance problems,
> >> the mork-db and the mime-parse, they are all working in synchronous way,
> >> so
> >> I have to figure out a way to calling these components
> >> in a worker directly, so that they would not cause UI-lag in
> main-thread.
> >> That's all the reason why I was trying to re-implement XPConnect with
> >> js-ctypes. So  that I can calling
> >> the exist components in the worker. And free the main-thread.
> >>
> >
> > Mork, by design, can't be used off main-thread. So even if you're trying
> > to subvert it by using JS-ctypes and etc., it's not going to work very
> > well, let alone the problems you have with trying to maintain a
> > pseudo-reimplementation of xpconnect.
> >
> >> 3、 There is an advantage of XPCOM, WebIDL seems merely for Javascript,
> but
> >> XPCOM seems more language-neutral, we could be able to
> >> use xpcom in Java/Python and other languages, that's looks like a
> >> advantage
> >> of XPCOM.
> >>
> > XPIDL is effectively a fork of an old version of IDL. Its interfaces are
> > incapable of cleanly representing union types or array types very well,
> > something that WebIDL does far better, as WebIDL is partly a fork of a
> > newer version of IDL. I believe there already exists WebIDL bindings for
> > C++, JS, and Rust, and extending it to Java or Python would not be a
> > challenging task. The only complexity is that the WebIDL bindings does
> not
> > use a grand-central dispatch mechanism like XPConnect, but that merely
> > means that adding new bindings requires writing a code generator and
> > feeding all the interfaces through it instead of implementing several
> > customized dispatch mechanisms. Not that PyXPCOM or JavaXPCOM have worked
> > for the past several years.
>
> The core issue is WebIDL is not usable in non-gecko code yet, I didn't see
> any example in thunderbird source tree, but I see lots of XPCOM codes. So I
> do not have any clue how to using WebIDL in thunderbird world
>

You would certainly need to blaze this trail. But it's certainly possible
(given that you're willing to fork mozilla-central), and I guarantee it
will be more tractable than rewriting XPConnect with JS-CTypes.


>
> >
> >
> > --
> > Joshua Cranmer
> > Thunderbird and DXR developer
> > Source code archæologist
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
>
>
>
> --
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Yonggang Luo 
On Tue, Jan 5, 2016 at 1:33 AM, Bobby Holley  wrote:

> On Mon, Jan 4, 2016 at 7:57 AM, 罗勇刚(Yonggang Luo) 
> wrote:
>
>> On Mon, Jan 4, 2016 at 11:37 PM, Joshua Cranmer  
>> wrote:
>>
>> > On 1/4/2016 9:24 AM, 罗勇刚(Yonggang Luo) wrote:
>> >
>> >> 1、I was not trying implement new things in xpcom, our company(Kingsoft)
>> >> are
>> >> maintaining a fork of thunderbird, and at the current time
>> >> We have to re-use existing XPCOM components that already exists in  the
>> >> thunderbid gecko world, beyond pure html
>> >> things, there is too much things we have to re-use(xpcom things), and
>> we
>> >> are facing  performance problems,
>> >> the mork-db and the mime-parse, they are all working in synchronous
>> way,
>> >> so
>> >> I have to figure out a way to calling these components
>> >> in a worker directly, so that they would not cause UI-lag in
>> main-thread.
>> >> That's all the reason why I was trying to re-implement XPConnect with
>> >> js-ctypes. So  that I can calling
>> >> the exist components in the worker. And free the main-thread.
>> >>
>> >
>> > Mork, by design, can't be used off main-thread. So even if you're trying
>> > to subvert it by using JS-ctypes and etc., it's not going to work very
>> > well, let alone the problems you have with trying to maintain a
>> > pseudo-reimplementation of xpconnect.
>> >
>> >> 3、 There is an advantage of XPCOM, WebIDL seems merely for Javascript,
>> but
>> >> XPCOM seems more language-neutral, we could be able to
>> >> use xpcom in Java/Python and other languages, that's looks like a
>> >> advantage
>> >> of XPCOM.
>> >>
>> > XPIDL is effectively a fork of an old version of IDL. Its interfaces are
>> > incapable of cleanly representing union types or array types very well,
>> > something that WebIDL does far better, as WebIDL is partly a fork of a
>> > newer version of IDL. I believe there already exists WebIDL bindings for
>> > C++, JS, and Rust, and extending it to Java or Python would not be a
>> > challenging task. The only complexity is that the WebIDL bindings does
>> not
>> > use a grand-central dispatch mechanism like XPConnect, but that merely
>> > means that adding new bindings requires writing a code generator and
>> > feeding all the interfaces through it instead of implementing several
>> > customized dispatch mechanisms. Not that PyXPCOM or JavaXPCOM have
>> worked
>> > for the past several years.
>>
>> The core issue is WebIDL is not usable in non-gecko code yet, I didn't see
>> any example in thunderbird source tree, but I see lots of XPCOM codes. So
>> I
>> do not have any clue how to using WebIDL in thunderbird world
>>
>
> You would certainly need to blaze this trail. But it's certainly possible
> (given that you're willing to fork mozilla-central), and I guarantee it
> will be more tractable than rewriting XPConnect with JS-CTypes.
>
>
In fact, the only reason to use WebIDL is to getting javascript to using
some native code, but the situation is I have no need to do that, all the
new code we've writing down are in pure Javascript, if we have the willing
to implement something with WebIDL, for example, the IMAP protocol, then we
would choose the pure javascript to do that, like the jsmime does.
The reason to rewriting XPConnect with JS-CTypes is not to use XPCOM  to
implement new things, but to re-use exist things.
Besides the mork database are only capable to running in main-thread, is
that possible to running the libmime in the worker?
Cause the libmime is really CPU intensive, I've seen it occupied 100% usage
of CPU, if that could be able to off main-thread, then that's would be a
great performance improvement.

>
>> >
>> >
>> > --
>> > Joshua Cranmer
>> > Thunderbird and DXR developer
>> > Source code archæologist
>> >
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>>
>>
>>
>> --
>>  此致
>> 礼
>> 罗勇刚
>> Yours
>> sincerely,
>> Yonggang Luo
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>


-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-04 Thread Yonggang Luo 
>
>
>> In fact, the only reason to use WebIDL is to getting javascript to using
>> some native code, but the situation is I have no need to do that, all the
>> new code we've writing down are in pure Javascript, if we have the willing
>> to implement something with WebIDL, for example, the IMAP protocol, then
>> we would choose the pure javascript to do that, like the jsmime does.
>> The reason to rewriting XPConnect with JS-CTypes is not to use XPCOM  to
>> implement new things, but to re-use exist things.
>>
>
> Are you talking about calling existing native code from JS? You can do
> that with WebIDL by writing binding entry points for the classes you want.
>
I am talking about calling existing XPCOM code from JS :( if it's existing
native code, the js-ctypes maybe enough.
That's why I am doing such a thing that you are thinking weird and not
necessary. Indeed, I am not willing to do that things too, but I still have
no other options yet.

>
> If you're talking about impersonating arbitrary XPCOM components with
> JS-implemented code...good luck doing that with anything other than
> XPConnect. ;-)
>
Hope that would works

>
>
>> Besides the mork database are only capable to running in main-thread, is
>> that possible to running the libmime in the worker?
>> Cause the libmime is really CPU intensive, I've seen it occupied 100%
>> usage of CPU, if that could be able to off main-thread, then that's would
>> be a great performance improvement.
>>
>>>
 >
 >
 > --
 > Joshua Cranmer
 > Thunderbird and DXR developer
 > Source code archæologist
 >
 > ___
 > dev-platform mailing list
 > dev-platform@lists.mozilla.org
 > https://lists.mozilla.org/listinfo/dev-platform
 >



 --
  此致
 礼
 罗勇刚
 Yours
 sincerely,
 Yonggang Luo
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

>>>
>>>
>>
>>
>> --
>>  此致
>> 礼
>> 罗勇刚
>> Yours
>> sincerely,
>> Yonggang Luo
>>
>
>


-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Bobby Holley 
As XPConnect module owner, I'd like to get it in record that we will almost
certainly not take this or any support code for it (i.e. code in js-ctypes)
in mozilla-central.

On Sun, Jan 3, 2016 at 11:46 AM, Joshua Cranmer  
wrote:

> On 1/3/2016 10:24 AM, 罗勇刚(Yonggang Luo) wrote:
>
>> So that we could be able to access xpcom in worker.
>> And we could be able  to implement thunderbird new msg protocol in pure
>> javascript
>>
>
> I will point out that Thunderbird developers are already looking into
> replacing the xpcom use of message protocols, so if that is the primary
> goal, then you are wasting your time, I am afraid.
>
> I will also point out that both JavaScript and C++ have moved on from the
> time xpconnect was developed to the point that use of xpconnect requires
> designing APIs that are uncomfortable to use from C++ or JavaScript (or
> even both!), so it is a much better investment of time to move APIs to
> newer paradigms than it is to try to develop a system that almost no one
> really understands.
>
> --
> Joshua Cranmer
> Thunderbird and DXR developer
> Source code archæologist
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Yonggang Luo 
On Mon, Jan 4, 2016 at 6:38 AM, Bobby Holley  wrote:

> As XPConnect module owner, I'd like to get it in record that we will almost
> certainly not take this or any support code for it (i.e. code in js-ctypes)
> in mozilla-central.
>
> Well, I was already have a modified version of mozilla-central, if the
upstream is not possible, then I just need to maintain the fork and can not
upstream the code.

> On Sun, Jan 3, 2016 at 11:46 AM, Joshua Cranmer  
> wrote:
>
> > On 1/3/2016 10:24 AM, 罗勇刚(Yonggang Luo) wrote:
> >
> >> So that we could be able to access xpcom in worker.
> >> And we could be able  to implement thunderbird new msg protocol in pure
> >> javascript
> >>
> >
> > I will point out that Thunderbird developers are already looking into
> > replacing the xpcom use of message protocols, so if that is the primary
> > goal, then you are wasting your time, I am afraid.
> >
> > I will also point out that both JavaScript and C++ have moved on from the
> > time xpconnect was developed to the point that use of xpconnect requires
> > designing APIs that are uncomfortable to use from C++ or JavaScript (or
> > even both!), so it is a much better investment of time to move APIs to
> > newer paradigms than it is to try to develop a system that almost no one
> > really understands.
> >
> > --
> > Joshua Cranmer
> > Thunderbird and DXR developer
> > Source code archæologist
> >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Bobby Holley 
Why not use webidl to expose the apis you want in workers?
On Jan 3, 2016 8:08 PM, "罗勇刚(Yonggang Luo)"  wrote:

>
>
> On Mon, Jan 4, 2016 at 6:38 AM, Bobby Holley 
> wrote:
>
>> As XPConnect module owner, I'd like to get it in record that we will
>> almost
>> certainly not take this or any support code for it (i.e. code in
>> js-ctypes)
>> in mozilla-central.
>>
>> Well, I was already have a modified version of mozilla-central, if the
> upstream is not possible, then I just need to maintain the fork and can not
> upstream the code.
>
>> On Sun, Jan 3, 2016 at 11:46 AM, Joshua Cranmer  
>> wrote:
>>
>> > On 1/3/2016 10:24 AM, 罗勇刚(Yonggang Luo) wrote:
>> >
>> >> So that we could be able to access xpcom in worker.
>> >> And we could be able  to implement thunderbird new msg protocol in pure
>> >> javascript
>> >>
>> >
>> > I will point out that Thunderbird developers are already looking into
>> > replacing the xpcom use of message protocols, so if that is the primary
>> > goal, then you are wasting your time, I am afraid.
>> >
>> > I will also point out that both JavaScript and C++ have moved on from
>> the
>> > time xpconnect was developed to the point that use of xpconnect requires
>> > designing APIs that are uncomfortable to use from C++ or JavaScript (or
>> > even both!), so it is a much better investment of time to move APIs to
>> > newer paradigms than it is to try to develop a system that almost no one
>> > really understands.
>> >
>> > --
>> > Joshua Cranmer
>> > Thunderbird and DXR developer
>> > Source code archæologist
>> >
>> >
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Yonggang Luo 
On Mon, Jan 4, 2016 at 3:46 AM, Joshua Cranmer  
wrote:

> On 1/3/2016 10:24 AM, 罗勇刚(Yonggang Luo) wrote:
>
>> So that we could be able to access xpcom in worker.
>> And we could be able  to implement thunderbird new msg protocol in pure
>> javascript
>>
>
> I will point out that Thunderbird developers are already looking into
> replacing the xpcom use of message protocols, so if that is the primary
> goal, then you are wasting your time, I am afraid.
>
> I will also point out that both JavaScript and C++ have moved on from the
> time xpconnect was developed to the point that use of xpconnect requires
> designing APIs that are uncomfortable to use from C++ or JavaScript (or
> even both!), so it is a much better investment of time to move APIs to
> newer paradigms than it is to try to develop a system that almost no one
> really understands.

It's a long time to talking about move away from xpcom, so that's would be
more time we still stay with xpcom.

>
>
> --
> Joshua Cranmer
> Thunderbird and DXR developer
> Source code archæologist
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Josh Matthews 

What is the motivation for this work?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Yonggang Luo 
So that we could be able to access xpcom in worker.
And we could be able  to implement thunderbird new msg protocol in pure
javascript

On Sun, Jan 3, 2016 at 11:09 PM, Josh Matthews 
wrote:

> What is the motivation for this work?
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Yonggang Luo 
1、After my investigation, I think it's possible to implement XPConnect with
JS-Ctypes.
2、And more than that,we could be possible to override Native C++ XPCOM
components with JS-Ctypes.
3、For support the full functional XPConnect in JS-Ctypes, we need to be
able to pass
the JSContext parameter along with JsObject with js-ctypes.


The following code the the exposed C API to be called with js-ctypes, so
that js-ctypes would be able to implement full functional XPConnect:



#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

using namespace mozilla;
static nsCOMPtr iim = nullptr;
static nsCOMPtr xpconnect = nullptr;
static nsCOMPtr registrar = nullptr;
static nsCOMPtr compMgr = nullptr;
static bool gShellInited = false;

#define NS_NULL_ID  \
  { 0x, 0x, 0x, \
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00} }

#define SHELL_EXPORT extern "C" NS_EXPORT

//
https://github.com/ivansafrin/Polycode/blob/master/Core/Contents/PolycodeView/MSVC/PolycodeView.cpp#L16
SHELL_EXPORT void OpenConsole(bool create)
{
  int outHandle, errHandle, inHandle;
  FILE *outFile, *errFile, *inFile;
  bool hasConsole  = AttachConsole(ATTACH_PARENT_PROCESS);
  if (!hasConsole) {
if (!create) {
  return;
}
FreeConsole();
AllocConsole();
  }

  CONSOLE_SCREEN_BUFFER_INFO coninfo;
  GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), );
  coninfo.dwSize.Y = ;
  SetConsoleScreenBufferSize(GetStdHandle(STD_OUTPUT_HANDLE),
coninfo.dwSize);

  outHandle = _open_osfhandle((intptr_t)GetStdHandle(STD_OUTPUT_HANDLE),
_O_TEXT);
  errHandle = _open_osfhandle((intptr_t)GetStdHandle(STD_ERROR_HANDLE),
_O_TEXT);
  inHandle = _open_osfhandle((intptr_t)GetStdHandle(STD_INPUT_HANDLE),
_O_TEXT);

  outFile = _fdopen(outHandle, "w");
  errFile = _fdopen(errHandle, "w");
  inFile = _fdopen(inHandle, "r");

  *stdout = *outFile;
  *stderr = *errFile;
  *stdin = *inFile;

  setvbuf(stdout, NULL, _IONBF, 0);
  setvbuf(stderr, NULL, _IONBF, 0);
  setvbuf(stdin, NULL, _IONBF, 0);

  std::ios::sync_with_stdio();
}

struct thread_data
{
  uint32_t sleep_time;
  int32_t exit_code;
  thread_data(uint32_t sleep_time, int32_t exit_code) :
sleep_time(sleep_time),
exit_code(exit_code) {
  }
};

DWORD WINAPI thread_func(LPVOID lpParameter)
{
  thread_data *td = (thread_data*)lpParameter;
  Sleep(td->sleep_time);
  ExitProcess(td->exit_code);
  return 0;
}

SHELL_EXPORT void ForceExit(uint32_t sleep_time, int32_t exit_code) {
  CreateThread(NULL, 0, thread_func, new thread_data(sleep_time,
exit_code), 0, 0);
}

SHELL_EXPORT void CopyBufferWithFree(void* destBuffer, void* sourceBuffer,
uint32_t length) {
  memcpy(destBuffer, sourceBuffer, length);
  NS_Free(sourceBuffer);
}

SHELL_EXPORT uint32_t CopyStringWithFree(char*destString, char*
sourceString, uint32_t destLength) {
  uint32_t tmpLength = strlen(sourceString);
  if (tmpLength <= destLength) {
memcpy(destString, sourceString, tmpLength);
  }
  NS_Free(sourceString);
  return tmpLength;
}

SHELL_EXPORT nsresult XPCOM_Init(const char* filePath) {
  if (gShellInited) {
return NS_OK;
  }
  nsresult rc = XPCOMGlueStartup(filePath);
  NS_ENSURE_SUCCESS(rc, rc);
  iim = do_GetService(NS_INTERFACEINFOMANAGER_SERVICE_CID, );
  NS_ENSURE_SUCCESS(rc, rc);
  xpconnect = do_GetService(nsIXPConnect::GetCID(), );
  NS_ENSURE_SUCCESS(rc, rc);

  rc = NS_GetComponentRegistrar(getter_AddRefs(registrar));
  NS_ENSURE_SUCCESS(rc, rc);
  rc = NS_GetComponentManager(getter_AddRefs(compMgr));
  gShellInited = true;
  return rc;
}

SHELL_EXPORT void* XPCOM_Alloc(size_t sz) {
  return NS_Alloc(sz);
}

SHELL_EXPORT void XPCOM_Free(void* ptr) {
  if (ptr) {
NS_Free(ptr);
  }
}

SHELL_EXPORT uint32_t XPCOM_nsStringSize() {
  return sizeof(nsString);
}

SHELL_EXPORT uint32_t XPCOM_nsCStringSize() {
  return sizeof(nsCString);
}

SHELL_EXPORT void XPCOM_ContractIDToCID(const char* contractID, nsCID* cid)
{
  nsCID* newCID;
  if (registrar->ContractIDToCID(contractID, ) == NS_OK) {
return CopyBufferWithFree(cid, newCID, sizeof(*cid));
  }
  *cid = NS_NULL_ID;
}

SHELL_EXPORT uint32_t XPCOM_CIDToContractID(const nsCID* cid, char*
contractID, uint32_t length) {
  char* newContractID;
  if (registrar->CIDToContractID(*cid, ) == NS_OK) {
return CopyStringWithFree(contractID, newContractID, length);
  }
  *contractID = '\0';
  return 0;
}

SHELL_EXPORT nsIFactory* XPCOM_GetClassObject(const char* contractID) {
  nsresult rc;
  nsCOMPtr sf = do_GetClassObject(contractID, );
  if (rc != NS_OK) {
return nullptr;
  }
  sf->AddRef();
  return sf;
}

SHELL_EXPORT nsIFactory* XPCOM_GetClassObjectCID(const nsCID *cid) {
  nsresult rc;
  nsCOMPtr sf = do_GetClassObject(*cid, );
  if (rc != NS_OK) {
return nullptr;
  }
  sf->AddRef();
  return sf;
}

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Yonggang Luo 
On Mon, Jan 4, 2016 at 12:35 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:

> Accessing XPCOM in a worker will most likely break the garbage-collector
> in novel and interesting ways, so I don't suggest heading in that
> direction.
>
> I'd like to hear more information about that,
For example, if I setting a finalize for  each XPCOM instance
Object(javascript), when the Object's is GCed, then I release
the xpcom instance, is that would not break the garbage-collector?
Or we have other problems about garbage-collector, I am interested in that.

>

> Cheers,
>  David
>
> On 03/01/16 17:24, 罗勇刚(Yonggang Luo)  wrote:
> > So that we could be able to access xpcom in worker.
> > And we could be able  to implement thunderbird new msg protocol in pure
> > javascript
> >
> > On Sun, Jan 3, 2016 at 11:09 PM, Josh Matthews 
> > wrote:
> >
> >> What is the motivation for this work?
>
>>
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >
> >
> >
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread David Rajchenbach-Teller 
Well, XPConnect is designed for the main thread, and many of the things
it does assume that everything takes place on the main thread.

An example, from the topic of my head: whenever objects cross between
JavaScript and C++ through XPConnect, they need to be retained in
hashtables to preserve unicity, etc. For performance reasons, these
hashtables are not protected against concurrent access.

Another example: JavaScript objects can point towards C++ objects and
vice-versa. The garbage-collector (well, the cycle-collector) needs to
walk the graph in specific ways to get rid of possible cycles that
involve both C++ and JS. The worker's implementation of the
cycle-collector is much simpler (and quite different) than the main
thread's, since it doesn't need to handle XPConnect. Mixing both
accidentally can lead to unpredictable results.

Oh, and XPConnect pointers can simply not be dereferenced from worker
threads. Attempting to do so will crash libxul by design to avoid accidents.

etc.

Cheers,
 David

On 03/01/16 17:45, 罗勇刚(Yonggang Luo)  wrote:
> 
> 
> On Mon, Jan 4, 2016 at 12:35 AM, David Rajchenbach-Teller
> > wrote:
> 
> Accessing XPCOM in a worker will most likely break the garbage-collector
> in novel and interesting ways, so I don't suggest heading in that
> direction.
> 
> I'd like to hear more information about that,
> For example, if I setting a finalize for  each XPCOM instance
> Object(javascript), when the Object's is GCed, then I release
> the xpcom instance, is that would not break the garbage-collector?
> Or we have other problems about garbage-collector, I am interested in that. 
> 
>  
> 
> Cheers,
>  David
> 
> On 03/01/16 17:24, 罗勇刚(Yonggang Luo)  wrote:
> > So that we could be able to access xpcom in worker.
> > And we could be able  to implement thunderbird new msg protocol in
> pure
> > javascript
> >
> > On Sun, Jan 3, 2016 at 11:09 PM, Josh Matthews
> >
> > wrote:
> >
> >> What is the motivation for this work?
> 
> >>
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> 
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >
> >
> >
> 
> 
> 
> 
> -- 
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Yonggang Luo 
On Mon, Jan 4, 2016 at 12:55 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:

> Well, XPConnect is designed for the main thread, and many of the things
> it does assume that everything takes place on the main thread.
>
> An example, from the topic of my head: whenever objects cross between
> JavaScript and C++ through XPConnect, they need to be retained in
> hashtables to preserve unicity, etc. For performance reasons, these
> hashtables are not protected against concurrent access.
>
I was maintaining the whole hashtable in the Javascript,  And the XPConnect
would be used any more, so that would be
a problem.

>
> Another example: JavaScript objects can point towards C++ objects and
> vice-versa. The garbage-collector (well, the cycle-collector) needs to
> walk the graph in specific ways to get rid of possible cycles that
>
involve both C++ and JS. The worker's implementation of the
> cycle-collector is much simpler (and quite different) than the main
> thread's, since it doesn't need to handle XPConnect. Mixing both
>
Does the worker's gc are implement in mark-swap way? or reference-count
based collector?
Cause I was implement the whole xpconnect in pure javascript, I think a
simple
mark-swap garbage collector should be suffice.
That's means, we only reference js object in javascript, and C++ object in
javascript,
 and we never reference Javascript object in C++, that's wold not affect
the worker's garbage-collector.

> accidentally can lead to unpredictable results.
>
> Oh, and XPConnect pointers can simply not be dereferenced from worker
> threads. Attempting to do so will crash libxul by design to avoid
> accidents.
>
> etc.
>
> Cheers,
>  David
>
> On 03/01/16 17:45, 罗勇刚(Yonggang Luo)  wrote:
> >
> >
> > On Mon, Jan 4, 2016 at 12:35 AM, David Rajchenbach-Teller
> > > wrote:
> >
> > Accessing XPCOM in a worker will most likely break the
> garbage-collector
> > in novel and interesting ways, so I don't suggest heading in that
> > direction.
> >
> > I'd like to hear more information about that,
> > For example, if I setting a finalize for  each XPCOM instance
> > Object(javascript), when the Object's is GCed, then I release
> > the xpcom instance, is that would not break the garbage-collector?
> > Or we have other problems about garbage-collector, I am interested in
> that.
> >
> >
> >
> > Cheers,
> >  David
> >
> > On 03/01/16 17:24, 罗勇刚(Yonggang Luo)  wrote:
> > > So that we could be able to access xpcom in worker.
> > > And we could be able  to implement thunderbird new msg protocol in
> > pure
> > > javascript
> > >
> > > On Sun, Jan 3, 2016 at 11:09 PM, Josh Matthews
> > >
> > > wrote:
> > >
> > >> What is the motivation for this work?
> >
> > >>
> > >> ___
> > >> dev-platform mailing list
> > >> dev-platform@lists.mozilla.org
> > 
> > >> https://lists.mozilla.org/listinfo/dev-platform
> > >>
> > >
> > >
> > >
> >
> >
> >
> >
> > --
> >  此致
> > 礼
> > 罗勇刚
> > Yours
> > sincerely,
> > Yonggang Luo
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread David Rajchenbach-Teller 
Accessing XPCOM in a worker will most likely break the garbage-collector
in novel and interesting ways, so I don't suggest heading in that direction.

Cheers,
 David

On 03/01/16 17:24, 罗勇刚(Yonggang Luo)  wrote:
> So that we could be able to access xpcom in worker.
> And we could be able  to implement thunderbird new msg protocol in pure
> javascript
> 
> On Sun, Jan 3, 2016 at 11:09 PM, Josh Matthews 
> wrote:
> 
>> What is the motivation for this work?
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> 
> 
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

2016-01-03 Thread Joshua Cranmer  

On 1/3/2016 10:24 AM, 罗勇刚(Yonggang Luo) wrote:

So that we could be able to access xpcom in worker.
And we could be able  to implement thunderbird new msg protocol in pure
javascript


I will point out that Thunderbird developers are already looking into 
replacing the xpcom use of message protocols, so if that is the primary 
goal, then you are wasting your time, I am afraid.


I will also point out that both JavaScript and C++ have moved on from 
the time xpconnect was developed to the point that use of xpconnect 
requires designing APIs that are uncomfortable to use from C++ or 
JavaScript (or even both!), so it is a much better investment of time to 
move APIs to newer paradigms than it is to try to develop a system that 
almost no one really understands.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform