Re: [orion-dev] Need help with creating an extension point

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Limiting the scope to commands that only
operate on 'the workspace' definitely simplifies the problem. For the basic
cases I think we can all see how this works. The GCLI core code lives in
the page where the command prompt appears. There is a console command provider
service ("extension point") that allows a plugin to declare new
console commands. It would take a command name and arguments, and return
either unstructured text, or minimally structured text that could easily
be serialized to JSON (simple lists, tables, etc). The same service could
also offer tab completion and help for each command. So far this can easily
be done from an Orion plugin, and could fit for example as a slideout on
the editor page. 

For use cases where a console command
produces a rich UI, one answer could be that invoking the command opens
another page that will contain that rich UI. I'm not sure I would want
such a rich UI to be squeezed onto the editor page anyway. To give an example
from the command line world, invoking "top" could open another
page with a sortable/interactive display of running processes. Even for
git commands it might be useful for the invocation to take me to another
page where I can more easily visualize the result (git diff and git merge
come to mind). Come to think of it, I could imagine "cd" in the
navigator taking me to another navigator page, or "ls" from the
editor taking me to the navigator page for that directory.

Anyway I don't have all the answers
here, I'm just thinking out loud about how all this comes together. Your
current direction of getting some basic textual commands going and building
from there sounds very reasonable.

John

Andy Clement <andrew.clement@xxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

03/05/2012 12:04 PM

Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>

To	Orion developer discussions <orion-dev@xxxxxxxxxxx>
cc
Subject	Re: [orion-dev] Need help with creating an extension point

> 1) A console "Section"
embedded in other Orion pages, such as the editor
> or navigator.
> 2) A single Orion console page (say http://orionhub.org/console/).
This
> single page would allow you to interact with all the various console
> extensions you have available.. Git, Cloud deployment, Rails console,
etc.

When Kris and I started playing, we went with (1) in the editor - which
was my initial view of how I'd like to use it. Using keybindings I can
slide it out to do some whatever-it-is and then close it again - I never
leave the editor tab.  We had this kind of working but it became apparent
that (currently) to make it a nice plugin we had to promote the CLI to
its own page rather than having a slideout.  I had hoped when it got
into orion core that we'll have the slideout support again (in the editor
certainly, perhaps elsewhere).

Having said that I can imagine a slideout is best for a simple targeted
activity against a few files, possibly only the file you are looking at
(if you slideout in the editor view).  So I can also see value in
a full page console where I have more screen area to work.  I'd hope
the same commands would work in both, it is just a question of how much
space I would want to get the job done.  I feel like if I saw a prompt
anywhere it ought to always offer the same commands.

Perhaps building on that there can be task based consoles which offer mostly
the CLI but maybe a bit of additional UI for the task you are trying to
achieve, but that could follow on from getting the basics going.

To offer a thought on Johns note:

> Hmm, when I use command line tools it is typically via a series of
putty windows. If I had my
> source code on one server, a second server for running builds, and
a third server where my 
> deployed application lived, I would have a separate putty window for
each. I wouldn't expect 
> commands for interacting with my deployed server to work from the
console on my source 
> control server, and vice versa. Apart from security problems with
that, I'm not even sure 
> how that would work. I.e., what does "ls" mean when my tooling
workflow spans several 
> servers like this? Which file system does it list? In an older world
where I could edit/build/run
> on a single box I can see how this works, but in software development
for the web
> I'm having trouble visualizing how a single monolithic console works.

My initial view had been that I want a console purely to interact with
the contents of my workspace and perform activities for which there is
no UI (either because it hasn't been built yet or because it will never
be built due to my funky use case).  I hadn't considered using the
console view as the bridge to 'other places' - it is an interesting point. 
On my regular desktop I can of course just open another terminal and putty,
but on my ipad I don't have that luxury.

cheers
Andy

On 5 March 2012 08:58, John Arthorne <John_Arthorne@xxxxxxxxxx>
wrote:
Hmm, when I use command line tools it
is typically via a series of putty windows. If I had my source code on
one server, a second server for running builds, and a third server where
my deployed application lived, I would have a separate putty window for
each. I wouldn't expect commands for interacting with my deployed server
to work from the console on my source control server, and vice versa. Apart
from security problems with that, I'm not even sure how that would work.
I.e., what does "ls" mean when my tooling workflow spans several
servers like this? Which file system does it list? In an older world where
I could edit/build/run on a single box I can see how this works, but in
software development for the web I'm having trouble visualizing how a single
monolithic console works. 

John

Andrew Eisenberg <andrew@xxxxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

03/05/2012 11:37 AM

Please respond to
andrew@xxxxxxxxxxxx; Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>

To	Orion developer discussions <orion-dev@xxxxxxxxxxx>
cc
Subject	Re: [orion-dev] Need help with creating an extension point

My personal opinion and expectation is that we would have one single page
that understands all console commands.  When I work on the command
line locally, I expect that I don't need to need different consoles for
each set of commands (eg- git vs vmc commands).  From an implementation
side, it might be easier to keep the consoles separate, but for a user
this is an unnecessary complication. 

Besides, even if we went with a separate console per extension, they would
still all need to recognize the basic commands (eg- cd, ls, pwd, ...).

So, from a user's point of view, I would prefer to see #1 or #2 below.



On Mon, Mar 5, 2012 at 8:11 AM, John Arthorne <John_Arthorne@xxxxxxxxxx>
wrote: 
Stepping back a bit, I'm wondering what the overall UI experience of the
command line will be, and how it will fit with other pages. Ignoring any
security or architectural limitations for a minute, would it look like:

1) A console "Section" embedded in other Orion pages, such as
the editor or navigator. 
2) A single Orion console page (say http://orionhub.org/console/).
This single page would allow you to interact with all the various console
extensions you have available.. Git, Cloud deployment, Rails console, etc.
3) Individual console pages for various tasks. For example, http://mygithost.org/console
to interact with a Git repository, http://cloudfoundry.org/console
to interact with a deployed cloud application, etc.


4) Something else? _______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev


_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev