search

spolu / breach_core

A Browser written in JS. Free. Modular. Hackable.
https://breach.github.io/breach_core/
MIT License
5.42k stars 412 forks source link

Recompile native modules #183

Open 3goats opened 9 years ago

3goats commented 9 years ago

Hi, Is there a requirement to re-compile native node modules when using with Breach as is required with Node-Webkit?

Carl

spolu commented 9 years ago

ATM yes and it's not properly supported but we're working hard to waive that requirement in the next version. breach_core will be a classical node module run by vanilla node in v0.4

3goats commented 9 years ago

OK - thanks for the clarification. Any idea on timescales for 0.4 ?

spolu commented 9 years ago

Hard to say you can track progress here: https://github.com/breach/exo_browser/issues/161

miketheprogrammer commented 9 years ago

@carlskii Native modules are very important to me to. I tried to get them to work naturally with the current Breach, but it just wasnt feasible. The next version of breach is going to use a more generic core, that is not built around node.

What does this mean?

  1. Native node modules will just work.
  2. You can still run node modules in the frontend with Browserify
  3. Breaches backing API (ExoBrowser) will be accessible from any Language that supports access to socket protocols.
  4. There will no longer be a hard dependence on an unstable version of Node. You use the version of node you feel comfortable with, rather than need to integrate with whatever we have put in.

So yes, please wait around for this next version :)

3goats commented 9 years ago

Interesting - regarding item 3 would ZeroMQ be a better choice here? There are language bindings for almost every language out there.

Carl

Sent from my iPhone

On 26 Jul 2014, at 11:35, Michael Hernandez notifications@github.com wrote:

@carlskii Native modules are very important to me to. I tried to get them to work naturally with the current Breach, but it just wasnt feasible. The next version of breach is going to use a more generic core, that is not built around node.

What does this mean?

  1. Native node modules will just work.
  2. You can still run node modules in the frontend with Browserify
  3. Breaches backing API (ExoBrowser) will be accessible from any Language that supports access to socket protocols.
  4. There will no longer be a hard dependence on an unstable version of Node. You use the version of node you feel comfortable with, rather than need to integrate with whatever we have put in.

So yes, please wait around for this next version :)

— Reply to this email directly or view it on GitHub.

miketheprogrammer commented 9 years ago

Not sure. It is up to @spolu on how it will be implemented. ZeroMQ is more for routing messages rather than strictly rpc over sockets. However, this http://zerorpc.dotcloud.com/ does seem nice.

But as I said it is up to @spolu. Whatever technology helps ExoBrowser, be a polyglot webrowser is fine with me.

spolu commented 9 years ago

I looked at zmq as it looked like a very good idea. But there are a few things that makes using a JSONRPC-ish protocol easier, in particular the miz of libraries available out of chromium base/ component... Additionally as @miketheprogrammer states it, we would have to really use it in a weird way to achieve RPC instead of just event passing.

3goats commented 9 years ago

Thanks - that did the trick.

miketheprogrammer commented 9 years ago

@carlskii let me know if you have any more questions. However @carlskii I should mention, feel free to write a module for breach that uses zmq. Possibilities are things like, Automated Browser testing. Once we have the ability to inject javascript, css, and interact with elements in a frame.

You should wait for 0.7 Exo / 0.4 Breach it will be a different beast.