[shpy-commit] r2938 - shpy/trunk/doc

[hpk at codespeak.net]

Author: hpk
Date: Mon Feb  9 20:13:33 2004
New Revision: 2938

Added:
   shpy/trunk/doc/shpy-goals.txt
      - copied, changed from r2937, shpy/trunk/doc/shpy-editor.txt
Log:
added a largely "enhanced" version of shpy-goals.txt 
in order to reach some consensus on what we want to
tackle.  (the most important goal to me is to get 
shpy self-containing: that it is possible to enhance
it using (another instance of) itself. 



Copied: shpy/trunk/doc/shpy-goals.txt (from r2937, shpy/trunk/doc/shpy-editor.txt)
==============================================================================
--- shpy/trunk/doc/shpy-editor.txt	(original)
+++ shpy/trunk/doc/shpy-goals.txt	Mon Feb  9 20:13:33 2004
@@ -1,11 +1,24 @@
-This is a tentative description of what I'd like to have next in shpy.
-What would be most useful for me is a general editing tool.  So I'll 
-just describe what I'm looking for, irrespective of the objections I can 
-already hear :-)
+This is a list of unprioritized goals for shpy. 
 
+programming shpy with shpy 
+--------------------------
 
-Goal:
-----
+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.
@@ -13,9 +26,15 @@
 $ 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, and several
-users opening the same file on the same host see each other's cursor and
-changes.  The pygame window works like a regular single-file editor.
+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
 
@@ -27,36 +46,33 @@
 all-encompassing window and the latter can always be added later.
 
 
-Setup:
------
-
-'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.
-
-There should be no need to run a shared server on the remote machine,
-but we need a way for 'shpy' to connect to the local client.  Some
-random solutions:
-
-0) shpy connects to $REMOTEHOST:8888.  Doesn't work in a lot of
-situations.
-
-1) start a shpy-client daemon process locally, listening to port 8888; 
-setup ~/.ssh/config so that ssh connexions automatically route the 
-remote port 8888 to the local port 8888; configure shpy to use this port 
-to connect back to shpy-client.  This way no separate process is needed 
-on the remote machine.
-
-2) 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.
-
-3) 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!
+Convenience
+-----------
 
+There is always stuff left to do for added convenience:
 
-Armin
+- '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.