Create browser extensions as a GSoC project

[sh19910711]

Hello, I'm one of possible students from GSoC 2015. I have submitted a proposal about browser extensions of web-console. Here is a public link of the proposal draft:

• https://github.com/sh19910711/google-summer-of-code-2015/blob/master/rails-web-console.md

What do you think of this? Please ask if you have anything unclear, because I'm quite new to this project, and I don't quite know how it works (but it interests me).

[sh19910711]

And also I'm not fluent in English, so I've prepared some figures to describe my proposal. The figures are pseudo-images (they are fake screens).

1. Main Feature

The browser extension allows to display the console aside from the web application's view (i.e., the console will be displayed in the web browser's developer tools):

2. Context Viewer

And one more thing - I'm thinking of implementing the context viewer which allows to view all variables in the current context. It will be something like the CSS viewer of Chrome DevTools, and its window will be docking with the console view:

[sh19910711]

Hello, again ✌️

Today, I have made an animated gif of context viewer as a mock-up (and fixed misunderstanding):

The change than before is that an array can be expanded in the viewer. Here is an example diff showing that change:

- @items: ["hello", "foo", "bar"]
+ @items: ▼
+     #<Item id: 1, ...> ▼
+         id: 1
+         name: "hello"
+     #<Item id: 2, ...> ▼
+         id: 2
+         name: "foo"
+     #<Item id: 3, ...> ▼
+         id: 3
+         name: "bar"

I think the context binding of the viewer will be the same as the console.

[gsamokovarov]

Yo @dhh, @jeremy, @chancancode and anyone interested in the development of this project: do you guys wanna chime in and share your ideas about our direction?

One of the ideas I want to explore is have the web-console be optionally always on. Meaning, you can introspect and evaluate code in every binding of the current execution stack. We may crash them Rubies, but its something I'm interested in trying out.

Whatever ideas and directions you guys have, we'll be thankful for all your feedback!

Cheers!

[dhh]

Love the idea of having the console be always on in development mode.

On Tue, Apr 21, 2015 at 11:03 AM, Genadi Samokovarov <
notifications@github.com> wrote:

Yo @dhh https://github.com/dhh, @jeremy https://github.com/jeremy,
@chancancode https://github.com/chancancode and anyone interested in
the development of this project: do you guys wanna chime in and share your
ideas about our direction?

One of the ideas I want to explore is have the web-console be optionally
always on. Meaning, you can introspect and evaluate code in every binding
of the current execution stack. We may crash them Rubies, but its something
I'm interested in trying out.

Whatever ideas and directions you guys have, we'll be thankful for all
your feedback!

Cheers!

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

[sh19910711]

Hi, all. This is an intermediate progress report of GSoC 2015, in short. 🍵

1. Add JavaScript Test Environment

PR #138

2. Add Close Button to Web Console

PR #140

3. Web Console in Chrome DevTools

http://brx-web-console.blogspot.jp/2015/06/web-browsers-developer-tools.html

And Next?

From this week, I will start to implement the context viewer experimentally. And so, welcome any comments, and welcome any claims. Let me know your thoughts about this project if you feel something in your heart.

Thanks.

[gsamokovarov]

Now that we have prototypes of the browser extensions, let's discuss where they should actually live.

1. Let them live in rails/web-console. I like this approach as everything is in one place and we can easily reuse the JavaScripts across every project. However, it does have the drawback of blowing up the repo with extension specific commits. We may also end up with extension specific maintainers and they will have access to all the codebase.
2. Let each of them live in own repositories. This has the benefit of easier to track history and project specific maintainers. The drawback is tricker JavaScripts reuse and maybe desynchronization of the projects. Say, the Chrome maintainers are more active and it has more features/less bugs than the Firefox and Safari extensions. This can happen in option 1 too, of course.

I generally lean over option 1, but I would like to hear your thoughts.

[sh19910711]

I haven't sorted out my ideas of that yet, but I think the browser extensions should be located as a sub-project of Web Console, and I think it is better, in that point, to put the code of the browser extensions under the rails/web-console, so plus one to the option 1 so far.

However, it does have the drawback of blowing up the repo with extension specific commits.

Yeah, that is my concern.

The drawback is tricker JavaScripts reuse and maybe desynchronization of the projects.

That is also. I need to think of that.

Thanks.