[pclasses-devel] some ideas for expanding P

[stephan b. <st...@s1...>]

Random thoughts:

- Add a more abstract process layer, such that we can do something like 
this:
  Process proc("http://...");
  proc.addArg( "foo=bar" );
  ...
  proc.start(...); // some flags might not be possible/appropriate
  ProcessIO * io = proc.processIO();

Maybe that already works? If so, please point me in the proper 
direction.


- Add support similar to s11n's acme::argv_parser class. This allows all 
client apps to read the args passed in to main(), but unfortunately 
requires that main() call either p_init( argc, argv ) or 
acme::argv_parser::args(argc,argv). Clients later call 
acme::argv_parser::args() to get the args. This is used in s11n by 
DLLs, so that they can plug in help options to a client's --help 
options. (See http://s11n.net/s11nconvert/ and grep for mysql-db, 
for an example.)
The exact args parser used is unimportant to me, but having access to 
argv from non-main() client code has often been convenient for me.

- An OO interface into the system environment, a-la eshell's env() 
function, which returns an acme::environment objects. Having a 
framework-level interface to it eases de/serialization of the data (for 
sessions support, etc) and allows things like toggling 
read/writability, logging, saving the env in another data structure, 
etc.

- Add an optional module for reading input from the console, using 
whatever input interface is available. See 
http://s11n.net/download/#readline_cpp, which supports stdin, GNU 
Readline or BSD editline. i realize this isn't a truly generic option 
for the framework, but it would allow really easy building of 
shell-like apps. This feature, combined with the next one, gives most 
shell-like apps all they need...

- Support for built-in functions which can be called by name, like 
eshell's support. This would primarily be of interest for shell-like 
apps, but could be used to provide some interesting features for 
controlling the framework from client code. Consider these calls:
	P::dispatch_command( "sleep 20" ); // dispatches to built-in
	P::dispatch_command( "konqueror http://..." ); // external app
	P::dispatch_command( "http://..." ); // uses protocol handler
	P::dispatch_command( "p-internal run-garbage-collector" );
Then we can wrap the whole back-end process/thread management behind a 
single interface. This is the main feature eshell provides, but i think 
the feature is suitable for a wide range of apps, not just shell-like 
ones.


Except for the Process stuff, i've got code to do all of this. i would 
need to pull it into the P tree, in the appropriate modules, and sed it 
to conform to P's naming conventions, but it would otherwise be trivial 
to do.


-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts