This is a list of unprioritized goals for shpy. 

programming shpy with shpy 
--------------------------

Enhance shpy to the point where it is convenient for two or more
people to enhance it using itself.  Perequesites:

- editing and saving files 

- triggering execution of the "shpy-beeing-currently-worked-on" 
  in a separate window.  It should be easy enough for multiple
  developers to launch a shared test-shpy-session. 

  the test session is different from the edit session in that
  it should use a different indepedent share-server in order to
  avoid messups between editing and testing. 


Editing and saving files 
-------------------------

Let's put aside matters of multiple cells and execution servers for the
moment.

$ shpy filename.txt

Opens filename.txt for editing.  The file is local to where the command
is issued, but it should just work transparently across ssh with all joining
parties seeing the same file.  Anyone should be able to trigger a 'save operation'
if that is not done automatigally, anyway. The save operation will be 
executed on the computer which opened the file.  However, we can easily
trigger a commit operation (using vpath's subversion-working-copy abstraction)
so that people can actually share interesting edit-states. 

Obsoleting IRC-clients during shpy-sessions
-------------------------------------------

$ shpy

Opens a scratch window.  Uses IRC mode cells, visible to everyone 
issuing a bare 'shpy' on the same machine.

In this model we edit several files and chat at the same time by having 
several windows on our screens.  Looks like an easier goal than a single 
all-encompassing window and the latter can always be added later.


Convenience
-----------

There is always stuff left to do for added convenience:

- 'shpy' is a small Python script that I put somewhere in my path so that
  I can just run it.  The PyGame-based client holds all the complexities
  and must be installed along with PyGame on the local machine.


- The shareserver defaults to starting 'shpyd' on some default port 
  and connecting to it.  Otherwise 'shpy' will connect to the
  specified shareserver (or some meta-server which keeps track
  of started session anywhere on the internet and even starts 
  itself new shareserver if you need a fresh one for starting a session
  with someone). 

- different kinds of execution (looping, restart every time,
  persistent==default). 

- start a more spidery shpy-client daemon that will issue ssh 
  connexions to the remote host(s) to listen for connexions from shpy.  We 
  can use named pipes instead of sockets in this situation.

- hack: assume 'ssh -X' and contact the remote X server, not to
  actually display the PyGame window, but to send information to the
  shpy-client daemon.  This could actually generalize to a seriously
  different framework in which you compile X with a Python extension that
  allows X clients to send Python scripts to the X server... Would be
  great too!  This is all a bit platform dependent, of course.