JSShell
44 views
Skip to first unread message
Ian Bicking
May 26, 2011, 1:50:30 PM5/26/11
to webb...@googlegroups.com
Cool to see what people are up to. I thought I'd continue with introductions and just give a quick overview of something I've hacked on some, JSShell (https://github.com/ianb/jsshell)
JSShell I guess might be different than some of the other tools in its minimal server interaction. The server component does very little except execute commands (basic signature: cwd, env, arglist) -- https://github.com/ianb/jsshell/blob/master/server.coffee#L19-L46 . It would be reasonable if it also had a few other routines for things like file access, but even then I ended up, for instance, using "find" to implement wildcard expansion. Anyway, from the start I was thinking about it as much as a replacement for bash as a replacement for a terminal. But that means giving up interaction pretty much entirely (though it's not impossible to imagine a chatty interaction between the server and client -- I'm curious how Well does this?) Piping is also inefficient if you pass it through the client, though for a large number of cases it's not bad really (and there's always "bash -c" to fall back onto).
One interesting side effect of a minimal server is that there's no server state. The server doesn't keep track of your current directory, foreground tasks, environment, etc... it's all kept on the client, and persists even if you lose the connection or restart the server. In fact it's all kept in serialized form in sessionStorage, so the session persists over restarts and reloads (also nice for testing during development).
I haven't actually gotten to doing anything very cool with JSShell, though -- it implements the basics and has some infrastructure for enhancing interactions, but I never wrote things to actually do that enhancing. So really I'd rather glom onto another project ;)
Ian
JSShell I guess might be different than some of the other tools in its minimal server interaction. The server component does very little except execute commands (basic signature: cwd, env, arglist) -- https://github.com/ianb/jsshell/blob/master/server.coffee#L19-L46 . It would be reasonable if it also had a few other routines for things like file access, but even then I ended up, for instance, using "find" to implement wildcard expansion. Anyway, from the start I was thinking about it as much as a replacement for bash as a replacement for a terminal. But that means giving up interaction pretty much entirely (though it's not impossible to imagine a chatty interaction between the server and client -- I'm curious how Well does this?) Piping is also inefficient if you pass it through the client, though for a large number of cases it's not bad really (and there's always "bash -c" to fall back onto).
One interesting side effect of a minimal server is that there's no server state. The server doesn't keep track of your current directory, foreground tasks, environment, etc... it's all kept on the client, and persists even if you lose the connection or restart the server. In fact it's all kept in serialized form in sessionStorage, so the session persists over restarts and reloads (also nice for testing during development).
I haven't actually gotten to doing anything very cool with JSShell, though -- it implements the basics and has some infrastructure for enhancing interactions, but I never wrote things to actually do that enhancing. So really I'd rather glom onto another project ;)
Ian
voracity
May 27, 2011, 11:02:20 PM5/27/11
to webby-cli
The approach I took with Well is somewhat similar.
The client keeps track of the current working location (either a
directory, file, location inside a file or an application) and command
history and you can also write commands in pure javascript. (The
client tries to run a command as javascript first, then passes it on
to the server if it can't find a matching function.) Well (the client
or the server) doesn't really have a concept of an environment beyond
the OS's default environment on the server (maybe I should change
that), however the client has 'contexts' which are objects with
properties/methods associated with the current location, managed by
whatever app is responsible for handling the current location. Aside
from dynamic changes to the current context, all of this survives
server restarts and page reloads because of being stored in either
sessionStorage or (for data about the location) the hash fragment.
The server behaves pretty much like a normal web server, and I've
tried to stick to a RESTful architecture. The web server does have
sessions (and hence a server state), which are mainly used for
authentication at the moment. Right now, sessions are stored in plain
text on the hard drive --- obviously not good, but it means they also
survive server restarts. I imagine there might be apps that make use
of sessions, particularly for managing multi-client interactions (e.g.
games, chat), but for single-client cases, I think sessionStorage,
etc. work best.
I hope all that made sense!
I think minimal servers (whose sole functions are to send out the
client app + provide a shared database) will become very important in
the future, so I find jsshell very interesting. Unfortunately, the
Well server certainly ain't minimal, largely because I'm also trying
to keep compatibility with existing programs and systems.
On May 27, 3:50 am, Ian Bicking <i...@colorstudy.com> wrote:
> Cool to see what people are up to. I thought I'd continue with
> introductions and just give a quick overview of something I've hacked on
> some, JSShell (https://github.com/ianb/jsshell)
>
> JSShell I guess might be different than some of the other tools in its
> minimal server interaction. The server component does very little except
> execute commands (basic signature: cwd, env, arglist) --https://github.com/ianb/jsshell/blob/master/server.coffee#L19-L46. It
The client keeps track of the current working location (either a
directory, file, location inside a file or an application) and command
history and you can also write commands in pure javascript. (The
client tries to run a command as javascript first, then passes it on
to the server if it can't find a matching function.) Well (the client
or the server) doesn't really have a concept of an environment beyond
the OS's default environment on the server (maybe I should change
that), however the client has 'contexts' which are objects with
properties/methods associated with the current location, managed by
whatever app is responsible for handling the current location. Aside
from dynamic changes to the current context, all of this survives
server restarts and page reloads because of being stored in either
sessionStorage or (for data about the location) the hash fragment.
The server behaves pretty much like a normal web server, and I've
tried to stick to a RESTful architecture. The web server does have
sessions (and hence a server state), which are mainly used for
authentication at the moment. Right now, sessions are stored in plain
text on the hard drive --- obviously not good, but it means they also
survive server restarts. I imagine there might be apps that make use
of sessions, particularly for managing multi-client interactions (e.g.
games, chat), but for single-client cases, I think sessionStorage,
etc. work best.
I hope all that made sense!
I think minimal servers (whose sole functions are to send out the
client app + provide a shared database) will become very important in
the future, so I find jsshell very interesting. Unfortunately, the
Well server certainly ain't minimal, largely because I'm also trying
to keep compatibility with existing programs and systems.
On May 27, 3:50 am, Ian Bicking <i...@colorstudy.com> wrote:
> Cool to see what people are up to. I thought I'd continue with
> introductions and just give a quick overview of something I've hacked on
> some, JSShell (https://github.com/ianb/jsshell)
>
> JSShell I guess might be different than some of the other tools in its
> minimal server interaction. The server component does very little except
voracity
May 27, 2011, 11:06:28 PM5/27/11
to webby-cli
Oh, also, not sure what you mean by 'chatty interaction', but if
you're talking about interactive command line programs, then Well
simply keeps the XHR channel open, outputting to screen as data comes
through the channel, and leaving a contenteditable <span> at the end
of the output for the user to send back responses at any time (over
another XHR channel). This setup *doesn't* survive a server restart.
you're talking about interactive command line programs, then Well
simply keeps the XHR channel open, outputting to screen as data comes
through the channel, and leaving a contenteditable <span> at the end
of the output for the user to send back responses at any time (over
another XHR channel). This setup *doesn't* survive a server restart.
> Cool to see what people are up to. I thought I'd continue with
> introductions and just give a quick overview of something I've hacked on
> some, JSShell (https://github.com/ianb/jsshell)
>
> JSShell I guess might be different than some of the other tools in its
> minimal server interaction. The server component does very little except
> execute commands (basic signature: cwd, env, arglist) --https://github.com/ianb/jsshell/blob/master/server.coffee#L19-L46. It
> introductions and just give a quick overview of something I've hacked on
> some, JSShell (https://github.com/ianb/jsshell)
>
> JSShell I guess might be different than some of the other tools in its
> minimal server interaction. The server component does very little except
Reply all
Reply to author
Forward
0 new messages