What services should the initial Context filesystem provide?

The Context app is now mountable as a virtual (WebDAV) filesystem. What should it do? It has a file at the top level called “README.html”, which is obvious enough. What should the README describe? What would you want a newcomer to be able to do from their favorite text editor (or their favorite file-aware programming language)? Browse classes and methods? Resume and suspend object memories? Add and remove code modules? Please share your thoughts, keeping in mind that this is meant to be a minimal system (one can always add code modules to it later).

This entry was posted on 19 December 2013 at 12:49 am and is filed under Context, Naiad, Smalltalk, Spoon with tags context, minimal, modules, remote browsing, smalltalk, spoon, squeak, virtual filesystem, webdav. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “What services should the initial Context filesystem provide?”

John Dougan Says:
21 December 2013 at 1:24 am

My thoughts: minimal base should be a machine parseable config info page that describes (or links to) image & module info sufficient for another system to automatically interface with it.

The next modules should be the load/unload module and some minimalist security configuration module. (read-only, r/w, not-visible?).

Past that, I’d want the obvious stuff: code editing, remote execution, process management etc. The things I’d need if I was writing a SLIME-like program that works with Spoon (SpLIME?). Some of this may not be best done via the file system, but the config info could be used to advertise where the service actually lives.

LikeLike

Reply
- Craig Latta Says:
  21 December 2013 at 8:03 am
  
  Thanks!
  
  Currently, each system has a MemoryProfile class, instances of which describe object memories known to the system (including the local system). A profile includes the system’s ID, name, and IDs of the services it provides. The current set of services is: GUI access, virtual filesystem (WebDAV), traditional web server, and remote messaging.
  
  The traditional web server provides initial instructions and memory control (resuming and suspending other memories). The virtual filesystem provides APIs for browsing processes and source code. Remote messaging provides history recording, module sharing, and all the other services. Full service discovery can happen over WebDAV or remote messaging. Security configuration would be a good thing to add.
  
  LikeLike
  
  Reply

thisContext