[GSOC2014] Project idea on cross platform app with node-webkit

Google Summer of Code
1

Hi Jason Kridner,

I am Ky, a grad student from UBC Canada. I am looking for a project proposal for this year GSOC and found that the Beagle Boards really interest me because of its rich I/O interfaces. I would love to work on the node-webkit starter application since I have both experiences on NodeJS and JavaScript. I made a CoAP proxy in NodeJS and CoAP client in JavaScript in my MS thesis (CoAP: Constrained Application Protocol for the Internet of Things).

I’d like to add a few thoughts regarding the idea. I have had a look on node-webkit app development and your getting-started app in node-webkit. I saw that in your app you still leave the address bar and some webkit controls (the back/forward/menu buttons). However, even if you remove these elements completely, it still does not look descend to me because it makes users feel they are working in a browser-with-limited-function application.

If you want a cross-platform solution, then I think Java + a web browser should be the best candidate. My suggestion would be you develop a background service/application that do all the device-level tasks such as mDNS, USB detect or SD programming. And such service/application opens a web service on local loopback interface such as localhost:8888 so that your web app from web browser can communicate to get the data and send control messages. I think Ajax messaging should work very seamlessly on even the oldest web browsers. This solution is even reusable in the Android/iPhone case that you develop your background service and use the same techniques.

Thus, end users just open your application, then their favorite web browser come up with something like localhost:8888 while the service/application run on the background.

However, if you still opt for the node-webkit solution, I am still capable, and I also have another idea that I think would make your application looks better. I would create the app follow a wizard-like style. Yes, users open the app, it tells what the users want, then depends on their selection, it continues with the corresponding instructions. That is much better than putting everything in one page and let users scroll from the top to the bottom with a bunch of texts. For instance: page 1 says “Please plug in your board into your PC/Laptop”, with some pictures; then once the board is detected, move to page 2: do this, do that, etc…

Well that’s my two cents. I hope you could find something interested in discussion. Please let me know your thoughts.

Thank you very much.

2

Hi Jason Kridner,

I am Ky, a grad student from UBC Canada. I am looking for a project proposal for this year GSOC and found that the Beagle Boards really interest me because of its rich I/O interfaces. I would love to work on the node-webkit starter application since I have both experiences on NodeJS and JavaScript. I made a CoAP proxy in NodeJS and CoAP client in JavaScript in my MS thesis (CoAP: Constrained Application Protocol for the Internet of Things).

I’d like to add a few thoughts regarding the idea. I have had a look on node-webkit app development and your getting-started app in node-webkit. I saw that in your app you still leave the address bar and some webkit controls (the back/forward/menu buttons). However, even if you remove these elements completely, it still does not look descend to me because it makes users feel they are working in a browser-with-limited-function application.

There are a couple of reasons for this. One, the early stage of the prototype doesn’t have a lot of refinement. Two, given the minimal functionality, it is desired to leave the ability to type in addresses and use it as a rudimentary browser. The primary use I’ve gotten out of the application so far has been to work with machines that have specifically prohibited installing the Chrome browser, but see this application as something specific enough to not bother blocking.

I certainly welcome changes that make it look more app-like in various use-cases.

If you want a cross-platform solution, then I think Java + a web browser should be the best candidate. My suggestion would be you develop a background service/application that do all the device-level tasks such as mDNS, USB detect or SD programming. And such service/application opens a web service on local loopback interface such as localhost:8888 so that your web app from web browser can communicate to get the data and send control messages. I think Ajax messaging should work very seamlessly on even the oldest web browsers. This solution is even reusable in the Android/iPhone case that you develop your background service and use the same techniques.

I believe the primary bottlenecks will be around having support libraries with sufficient control and high-level programmability over the various USB stacks. The GitHub - ungureanuvladvictor/BBBlfs: Flash your BeagleBone Black via USB project was well on its way to providing a library that could be built and run across most operating systems, but issues were encountered on Mac machines. I don’t know that there is a Java API that would fare any better.

Do you have any USB programming experience in Java?

Thus, end users just open your application, then their favorite web browser come up with something like localhost:8888 while the service/application run on the background.

However, if you still opt for the node-webkit solution, I am still capable, and I also have another idea that I think would make your application looks better. I would create the app follow a wizard-like style.

Great.

Yes, users open the app, it tells what the users want, then depends on their selection, it continues with the corresponding instructions. That is much better than putting everything in one page and let users scroll from the top to the bottom with a bunch of texts. For instance: page 1 says “Please plug in your board into your PC/Laptop”, with some pictures; then once the board is detected, move to page 2: do this, do that, etc…

I’ve certainly always wanted to see it implemented in a wizard-like style, but I think the integration aspects are even more critical.

Well that’s my two cents. I hope you could find something interested in discussion. Please let me know your thoughts.

It is certainly of interest to me. Need to gain some interest from the community.

3

Thanks for your reply.

With respect the integration, I think this is a totally a new problem to address. Because there are only two ways to interact with the board, via Network connection or via USB connection (please correct me if I’m wrong), while the networking should be straight forward, the USB connection would require more effort. Then the requirement could be rephrased to designing a cross-platform USB stack to communicate with the board.

I had a few researches and there is a module for NodeJS that provide USB access, however it still depends on the libusb, which requires user to install libusb before using the NodeJS USB module. This does not look like a cross-platform solution and for all other language such as C or Java, you still require the same libusb from the user (your provided link to GSoC2013 project also asks user to install libusb first).

Last, could you please clarify me a little bit more. As I saw from the doc, we had drivers for Windows and Linux (not actually driver), but the driver seems to be only for the USB-Ethernet connection. I think the integration we are discussing should lay in the driver layer, not the application. Then the driver could be updated to add USB communication APIs so that the getting-started application or whatever application else can benefit from.

How do you think?

4

Thanks for your reply.

With respect the integration, I think this is a totally a new problem to address. Because there are only two ways to interact with the board, via Network connection or via USB connection (please correct me if I’m wrong), while the networking should be straight forward, the USB connection would require more effort.

Bootloading over the network is possible, but I don’t think that is necessarily simpler than over USB. Bootloading over USB at least has a partially completed library that could be used as reference. Personally, I’d prefer to replace the networking code with JavaScript to make it port more easily to platforms that already have node.js, but that isn’t strictly a requirement.

Then the requirement could be rephrased to designing a cross-platform USB stack to communicate with the board.

That’s the most complicated building block, but there is also the matter of creating simple-to-use wizards for downloading and flashing the images.

I had a few researches and there is a module for NodeJS that provide USB access, however it still depends on the libusb, which requires user to install libusb before using the NodeJS USB module. This does not look like a cross-platform solution and for all other language such as C or Java, you still require the same libusb from the user (your provided link to GSoC2013 project also asks user to install libusb first).

I think a dependency on libusb is OK, as long as it can be shown to work on Linux, Mac and Windows.

Last, could you please clarify me a little bit more. As I saw from the doc, we had drivers for Windows and Linux (not actually driver), but the driver seems to be only for the USB-Ethernet connection. I think the integration we are discussing should lay in the driver layer, not the application. Then the driver could be updated to add USB communication APIs so that the getting-started application or whatever application else can benefit from.

How do you think?

That mostly sounds right, but I’d like to see some drawings to help solidify the understanding.