Thrust will be rebasing off of Atom Shell

[miketheprogrammer]

Hey contributors, users, and fans. Over the next few months as I have time, I will be planning and implementing the rebasing of Thrust to Atom Shell. What does this mean. Well, we are all familiar with the problems of Atom-Shell, and those are the reasons we choose to stay with Thrust, for instance, lack of Polyglot api, retargeting C Node Modules for the specific version of node used to compile Atom-Shell, and a host of other issues that ExoBrowser as well faced prior to Thrust.

Due to the complex nature of working with the Blink API, thrust as it stands is just not feasible for a long term project, with no financial backing, nor C programmers whom are willing to commit the time to maintaining it. We already use Brightray which is the Chromium Content Library wrapper that Atom-Shell uses as is infact built by ZCBenz as well, now we will be taking it one step further and using Atom-Shell as the basis for our Thrust EcoSystem.

We are beginning to look at Thrust as a standard for Polyglot application development using Chromium Content Library, rather than as a specific implementation.

What does this look like, well we will code the same RPC abilities into Atom-Shell, and use that as the "Thrust" core module, and the *-Thrust modules will download it, consume it, and launch it the same exact way.

I promise to try to maintain 100% backwards compatibility being the author of Go-Thrust as well. My goal is to enable stability, features, and hope for those of you looking to use this technology in Products and Business settings.

As well if I cannot maintain backwards compatibility I will try to submit pull requests to the *-Thrust repositories, or at least assist in upgrading.

Thank you all for your support and love of Thrust. I hope to be able to create something stable for you.
I am just one man ( a busy one at that ) so any help, contributions, ideas, thoughts, criticisms, are very welcome.

Sincerely,
Michael Hernandez

[joshmarinacci]

Does this still mean that Node and chromium will be in separate processes? My problem with atom shell has always been that I have to get my code working with the particular version of Node inside of Atom Shell. I could never get node-serialport working properly with it, but with Thrust it was a cinch.

[miketheprogrammer]

@joshmarinacci Yea, the point is to maintain Thrust's current system and flow, almost completely, If i can't do that, then I will not commit the change. In this new version, you will have Node available in chrome, however only in so far as a helper. There will be no APM to install and retarget native modules.
For 99% of your backend javascript you will still use a seperate node process.

Thrust will be the Bridge between Atom Shell and your Node process. With possibly its own fork of AtomShell. Heres the current Segmentation of Technologies

Blink/V8 ==> Brightray and Embedded Node ==> Atom-Shell (With injectable Shell)

Blink/V8 ==> Brigtray ==> Thrust ===> Node

What I want to do

Blink/V8 ==> Brighray and Embedded Node ==> Atom-Shell (with Thrust as Injected Shell) ==> (NodeJS, GoLang, Python, Scala, Perl, ...)

[benjiqq]

@spolu @miketheprogrammer I like the programmable browser concept very much and hope this work continues. How does this tie in with the first exobrowser concept?

Say, in theory, somebody (with a large pocket of $) would want to write a programmable browser from scratch. It seems the challenge is that browsers are not really meant to be programmable in this way, in the first place. So we end up with a gigantic stack full of C++/JS/HTML/CSS. Certainly Google has thought of this and try to get around this with things like polymer and Dart, if I understand correctly. Javascript applies to content, not the framework (browser), i.e. browser plugins are secondary. The clever hack of exobrowser was to bootstrap this process by introducing the idea of writing browsers in HTML/JS/CSS themselves.

Are there any other possible scenarios to reaching the end goal?

[hoytech]

Hi!

Just wanted to let you guys know I have uploaded a library that lets you control electron (formerly known as atom-shell) with another process via pipes and JSON messages, similar to how Thrust works. In fact, Thrust was my main inspiration for this project:

https://github.com/hoytech/valence

I agree that Thrust's approach of not dictating controller language/run-time is the right way to go, however my concern with standardising on the Thrust API is that its feature-set is very limited compared to electron's. Valence is essentially an RPC bridge so it should support everything that electron does.

Here are the perl language bindings:

https://metacpan.org/pod/Valence

Cheers,

Doug

[spolu]

This is awesome. I'll hack on it right away!

On Monday, April 27, 2015, Doug Hoyte notifications@github.com wrote:

Hi!

Just wanted to let you guys know I have uploaded a library that lets you
control electron (formerly known as atom-shell) with another process via
pipes and JSON messages, similar to how Thrust works. In fact, Thrust was
my main inspiration for this project:

https://github.com/hoytech/valence

I agree that Thrust's approach of not dictating controller
language/run-time is the right way to go, however my concern with
standardising on the Thrust API is that its feature-set is very limited
compared to electron's. Valence is essentially an RPC bridge so it should
support everything that electron does.

Here are the perl language bindings:

https://metacpan.org/pod/Valence

Cheers,

Doug

—
Reply to this email directly or view it on GitHub
#272 (comment).

[spolu]

I'll probably rewrite https://github.com/spolu/node-shell on top of valence
and call it bivalence :)

The overarching goal being the support of npm install xxx and it just
works.

On Wed, Apr 29, 2015 at 8:25 AM, Stanislas Polu polu.stanislas@gmail.com
wrote:

This is awesome. I'll hack on it right away!

On Monday, April 27, 2015, Doug Hoyte notifications@github.com wrote:

Hi!

Just wanted to let you guys know I have uploaded a library that lets you
control electron (formerly known as atom-shell) with another process via
pipes and JSON messages, similar to how Thrust works. In fact, Thrust was
my main inspiration for this project:

https://github.com/hoytech/valence

I agree that Thrust's approach of not dictating controller
language/run-time is the right way to go, however my concern with
standardising on the Thrust API is that its feature-set is very limited
compared to electron's. Valence is essentially an RPC bridge so it should
support everything that electron does.

Here are the perl language bindings:

https://metacpan.org/pod/Valence

Cheers,

Doug

—
Reply to this email directly or view it on GitHub
#272 (comment).

[spolu]

The valance equivalent being this currently:
https://github.com/spolu/node-shell/blob/master/wrapper/index.js

On Sat, May 2, 2015 at 10:36 AM, Stanislas Polu polu.stanislas@gmail.com
wrote:

I'll probably rewrite https://github.com/spolu/node-shell on top of
valence and call it bivalence :)

The overarching goal being the support of npm install xxx and it just
works.

On Wed, Apr 29, 2015 at 8:25 AM, Stanislas Polu polu.stanislas@gmail.com
wrote:

This is awesome. I'll hack on it right away!

On Monday, April 27, 2015, Doug Hoyte notifications@github.com wrote:

Hi!

Just wanted to let you guys know I have uploaded a library that lets you
control electron (formerly known as atom-shell) with another process via
pipes and JSON messages, similar to how Thrust works. In fact, Thrust was
my main inspiration for this project:

https://github.com/hoytech/valence

I agree that Thrust's approach of not dictating controller
language/run-time is the right way to go, however my concern with
standardising on the Thrust API is that its feature-set is very limited
compared to electron's. Valence is essentially an RPC bridge so it should
support everything that electron does.

Here are the perl language bindings:

https://metacpan.org/pod/Valence

Cheers,

Doug

—
Reply to this email directly or view it on GitHub
#272 (comment).

[hoytech]

Hehe bivalence -- that is a great name. :)

Thanks for the pointer to node-shell, it actually looks like a pretty similar idea to valence.

Agreed: Ideally users should just be able to npm/cpan/whatever and have everything working.

[rrohrer]

Hey all, roughly, what is the status on this? Is there a set of TODOs laying around so other can help out?

[miketheprogrammer]

Cancelled. Suffered an injury can't code much open source anymore
On Dec 2, 2015 2:27 PM, "Ryan Rohrer" notifications@github.com wrote:

Hey all, roughly, what is the status on this? Is there a set of TODOs
laying around so other can help out?

—
Reply to this email directly or view it on GitHub
#272 (comment).

[rrohrer]

Sorry to hear that.

[rrohrer]

Hey all. I was inspired by @hoytech's valence, but wanted something with a slightly less low level control (and that worked on windows since Electron doesn't allow stdin/stdout).

As a solution, I came up with electroncontrol and wrote bindings for go go-electroncontrol It's significantly less flushed out than Thrust, but combined with go-bindata (to pack in dependencies and ship a single exe that auto expands) it's enough to ship my simple app (and probably others like it).

It's convenient to be able to run purely on a downloaded exe of electron.

I figured I'd share here because moving Thrust to electron was a great idea, and hopefully other people think this solution is 'good enough' as well.

/shameless self promoting

[miketheprogrammer]

Not shameless, we all want to build great technologies. I accept this
promotion. Feel free to submit a pull request to the read me and desbribe
it as an alternative
On Dec 11, 2015 3:03 AM, "Ryan Rohrer" notifications@github.com wrote:

Hey all. I was inspired by @hoytech https://github.com/hoytech's
valence, but wanted something with a slightly less low level control (and
that worked on windows since Electron doesn't allow stdin/stdout).

As a solution, I came up with electroncontrol
https://github.com/rrohrer/electroncontrol and wrote bindings for go
go-electroncontrol https://github.com/rrohrer/go-electroncontrol It's
significantly less flushed out than Thrust, but combined with go-bindata
https://github.com/jteeuwen/go-bindata/ (to pack in dependencies and
ship a single exe that auto expands) it's enough to ship my simple app (and
probably others like it).

It's convenient to be able to run purely on a downloaded exe of electron.

I figured I'd share here because moving Thrust to electron was a great
idea, and hopefully other people think this solution is 'good enough' as
well.

/shameless self promoting

—
Reply to this email directly or view it on GitHub
#272 (comment).

[SeinopSys]

I guess all good things come to and end 😢
This was a great Idea that I really wanted to see rise, shame it has to end because of an injury. Get well soon!

[ziahamza]

Get well soon buddy, I read about this project a while back, but did not know that you stopped working on this. Hope you are doing well!

[miketheprogrammer]

I am a little better, starting to maintain it again

On Wed, Feb 24, 2016 at 9:22 AM, hamza zia notifications@github.com wrote:

Get well soon buddy, I read about this project a while back, but did not
know that you stopped working on this. Hope you are doing well!

—
Reply to this email directly or view it on GitHub
#272 (comment).

[SeinopSys]

starting to maintain it again

[RWOverdijk]

:D

[miketheprogrammer]

that doesnt mean new features in thrust, just maitenance of go-thrust

On Wed, Feb 24, 2016 at 9:55 AM, Wesley Overdijk notifications@github.com
wrote:

:D

—
Reply to this email directly or view it on GitHub
#272 (comment).