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

What are your plans for supporting stacks of frames #5

Open
miketheprogrammer opened this issue Jul 20, 2014 · 9 comments
Open

What are your plans for supporting stacks of frames #5

miketheprogrammer opened this issue Jul 20, 2014 · 9 comments

Comments

@miketheprogrammer
Copy link

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.

@spolu
Copy link
Owner

spolu commented Jul 21, 2014

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 tag. See google chrome apps for an example.

I'll probably call it the exo shell ;-)

@spolu
Copy link
Owner

spolu commented Jul 21, 2014

^ webview tag

@spolu
Copy link
Owner

spolu commented Jul 21, 2014

Most lacking thing we will have a hard time getting into atom is support for sessions

@miketheprogrammer
Copy link
Author

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
#5 (comment).

@miketheprogrammer
Copy link
Author

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

@spolu
Copy link
Owner

spolu commented Jul 21, 2014

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 :-)

@spolu
Copy link
Owner

spolu commented Jul 21, 2014

I'll add you to the org and will assign you a couple issues ASAP if ok with you??

@miketheprogrammer
Copy link
Author

@spolu That is completely okay with me.

@spolu
Copy link
Owner

spolu commented Jul 21, 2014

Awesome!

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

No branches or pull requests

2 participants