node-shell
node-shell copied to clipboard
What are your plans for supporting stacks of frames
So far atom-shell seems built for handling one frame, with javascript and html managing the rest. It this the way Exo was built? Seems like there will have to be some communication between node and the browsernode and the webpage to manage Iframes in a stack context. Not sure if you had other more elegant ideas.
I gave a lot of thinking to this over the weekend
I think I'll go back to using the exo browser but will remove node from it and expose the API through RPC only bind able over any language.
The stack of frame requires what is the next logical step... The
I'll probably call it the exo shell ;-)
^ webview tag
Most lacking thing we will have a hard time getting into atom is support for sessions
Makes a lot of sense. Might be easier to keep it node for the rpc. And just turn breach into the rpc client. On Jul 21, 2014 12:58 AM, "Stanislas Polu" [email protected] wrote:
Most lacking thing we will have a hard time getting into atom is support for sessions
— Reply to this email directly or view it on GitHub https://github.com/spolu/node-shell/issues/5#issuecomment-49572036.
@spolu +1 for Webview tag : just read the docs +1 for keeping the exo_browser. I like brightly and atomshell, but I approve of what you have done with the exo browser. +1 for Either keeping nodejs in exo or using some native rpc style. However, I would recommend NodeJS. Why? Because its higher level, you just speak the json protocol. And it supports streaming. There is alot more you can do with NodeJS powering the ExoBrowser API interface. +1 For Breach being an RPC client. This will allow for endusers to use any version of NodeJS they feel comfortable with, as well.
While some of the above add a bit of system resource overhead, I dont think it is too much. I am also willing to help with any of the C(++) or Javascript programming, as well as bugs.
Nice!
Concerning nodeJS I feel likes it's a total overhead. Over unix domain sockets there's nothing nodeJS can do that C cannot, right?
This would lighten the code base, allow us to get rid of the event loop integration and free us from the weird feeling that there are two instances of nodeJS running across the techno stack of breach!
Finding the right API is definitely a major focus for this transition but I hope we can get rid of nodeJS in ExoBrowser :-)
I'll add you to the org and will assign you a couple issues ASAP if ok with you??
@spolu That is completely okay with me.
Awesome!