ChromeWorkers

[aplicacionamedida]

Hi Akio Tajima,
I made some improvement in FireRuby. I use ChromeWorkers, which are threads on the Chrome. There is also WebWorkers, which are threads but not in the Chrome. Threads are useful for cpu intensive tasks, because otherwise you freeze the GUI. Try for example a sleep in your FireRuby. The GUI is not responsive. You can check this including a button and attaching an alert to the click event. Clicking the button no alerts fires. But with ChromeWorkers this problem is solved. It's necessary to use ChromeWorkers instead of Webworkers, because we use the XPCOM js-ctypes. Using XPCOM components is only possible on the chrome.

For the communication on the other side, from the secondary thread to the main thread I use postMessage().

I also tried different tricks to extract the pointer address of a function in javascript, in this case ruby_postMessage(), which is connected to the postMessage() method. This address is passed to the main.rb script. I extracted this address using the string representation of the javascript object.

I think that it's totally possible to code hybrid web apps using xulrunner embedding an interpreter.

Best regards,
Miguel.

[Noitidart]

Very very interesting work!

[arton]

Hi Miguel
Sorry for my late response. And thanks for your advice.
I'll check and merge it soon, Thanks agin.

[aplicacionamedida]

Thanks Noitidart for your comment. I also saw your comment and your puntuation on sourceforge: http://sourceforge.net/projects/firetcl

XUL and XPCOM has been deprecated this august. You can see here:
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

What will be your approach now Akio Tajima?

I explain my intentions here:
http://wiki.tcl.tk/41658

[Noitidart]

Thanks @aplicacionamedida for that note on seeing them :)
If I can help I would really love to. I do documentation on MDN. A dev wrote a js-ctypes module for JNI, so we can use it on Android and other places and i documented it on MDN here: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/JNI.jsm

So I would love to help you with doucmentation on making a product with this. :)

[Noitidart]

Alos yep XUL and XPCOM are going, but js-ctypes is here to stay! I will be able to gurantee this js-ctypes soon but it's very unlikely its going anywhere. A huge core of Firefox is in js-ctypes, the whole OS.File system and we are moving towards that as it is full async.

[aplicacionamedida]

I were about to give up this project and to start another using a local websocket server to send Tcl code for evaluation and also a Tcl to javascript compiler. Your information very probably will change my direction: I will continue the development of FireTcl. Anyway the other approach using a local websocket server allows the evaluation of Tcl code in any browser and without any restrictions. I want also to continue this work.

js-ctypes and workers with chrome privilegies guives the possibility to eval code of other programming languages. This means that it's possible to program desktop web applications using only your favourite programming language in a very easy and simple solution. I demostrated this in my library FireTcl.

I have understood that the new browser e10s will guive support to the High-level APIs of the firefox SDK:
https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK

The problem is that SDK hasn't true workers:
"The Worker is similar to the web worker interface defined by the W3C. But unlike "web workers," these workers run in the same process as web content and browser chrome, so code within workers can block the UI."

Source: https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/content_worker

XUL will be deprecated. It could be nice a feature to load a website without the navigation bar. Chrome has this possibility. For example, calling the next command the website https://www.google.com/ is loaded without the navbar:
google-chrome --app=https://www.google.com/

I am using XUL in FireTcl only to achieve the same effect. This feature would have an important impact in the development of desktop web applications.

Some insights:

• Using js-ctypes for building a bridge to other programming languages is more efficient than using a local websocket server for code evaluation. Also this solution, using js-ctypes, avoids the problem with firewalls.
• There is other solutions for building desktop web applications: node-webkit and electron. The drawback of these solutions is its big size because they embed an entire web rendering engine in the application. A simple hello world application has a minimum size of 50 MB in node-webkit and in electron is much more. FireTcl avoids this problem. It uses the browser installed on the user machine.

I have to thank you Noitidart all your support.

[Noitidart]

This is super cool. XUL isn't going anywhere yet, it's too essential to Firefox so will be there for next two years. So we can use XUL to get that affect of no nav bar, and as soon as the next stuff comes around we can move to that, they'll give us months to port, and it wont be hard. The XUL replacement is very web component like.

If our use of XUL is only to get rid of the navbar ill do some research I did some command line stuff Ill see if we can open it bare, Im pretty sure there is a way because WebApps open like this.

Those insights are extremely extremely awesome news!! I really am a fan of this project and really can't wait to document the basics and a guide from start to finish to example such as this one I wrote here: Following the Android Toasts Tutorial from a JNI Prespective - From Zero to Finished Runnable Code

Wowwww 50mb for hello world! That is amazing, so glad to hear our moz method is much simpler. I also was exploring this the other day: trueinteractions/tint2#161 (comment)

I created a forum topic about it here: https://discourse.mozilla-community.org/t/application-dev-via-addons-not-as-popular-for-firefox-how-come/3686

Basically these people at true interactions are also doing desktop applications and it is getting quite a bit of attraction. But they are doing stuff from scratch. With Moz technology we already have stuff established and it's more robust. I think with your Tcl we'll be able to see some really nice works out there! I want to thank you so much for this! It is incredible! It gets me really motivated! :)

[Noitidart]

Also a quick update, i read your wiki:

: I use the XPCOM component js-ctypes

js-ctypes is not XPCOM at all thankfully :)

And that bridge of child_process you mentioned in the wiki is actually js-ctypes based, another core tech that WebExt API will rely on. So js-ctypes future is 95% sound. I give 5% because I haven't heard from the top dogs yet haha but I did from the other dogs! :)

[Noitidart]

I forgot to mention that ChromeWorkers are unlikely to go anywhere either as all the js-ctypes happens in these workers. Reviewers don't accept ctypes on the main thread I think, due to the ui blocking.

[aplicacionamedida]

Thanks for your reassuring message about the future of firefox. I want to provide a debugging tool for Tcl code evaluation in an external editor. I will change also the code of the clipboard. I want to add also a task manager for the Tcl code evalution in workers. What's your email? My email is at the end of the README file of my library.

[Noitidart]

Thanks @aplicacionamedida my email is [email protected] I'll find your email and send you a note!