|
From: stephan b. <st...@s1...> - 2004-12-19 13:39:48
|
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
|