On Mon, Jan 4, 2016 at 10:01 AM, 罗勇刚(Yonggang Luo) <luoyongg...@gmail.com> wrote:
> > > On Tue, Jan 5, 2016 at 1:33 AM, Bobby Holley <bobbyhol...@gmail.com> > wrote: > >> On Mon, Jan 4, 2016 at 7:57 AM, 罗勇刚(Yonggang Luo) <luoyongg...@gmail.com> >> wrote: >> >>> On Mon, Jan 4, 2016 at 11:37 PM, Joshua Cranmer 🐧 <pidgeo...@gmail.com> >>> 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 https://lists.mozilla.org/listinfo/dev-platform
