Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recompile native modules #183

Open
3goats opened this issue Jul 25, 2014 · 9 comments
Open

Recompile native modules #183

3goats opened this issue Jul 25, 2014 · 9 comments
Labels

Comments

@3goats
Copy link

3goats commented Jul 25, 2014

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

Carl

@spolu
Copy link
Owner

spolu commented Jul 25, 2014

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

@spolu spolu added the Question label Jul 25, 2014
@3goats
Copy link
Author

3goats commented Jul 25, 2014

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

@spolu
Copy link
Owner

spolu commented Jul 25, 2014

Hard to say you can track progress here: breach/thrust#161

@miketheprogrammer
Copy link

@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
Copy link
Author

3goats commented Jul 26, 2014

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 [email protected] 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
Copy link

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
Copy link
Owner

spolu commented Jul 28, 2014

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
Copy link
Author

3goats commented Jul 29, 2014

Thanks - that did the trick.

@miketheprogrammer
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants