Re: [pclasses-devel] some ideas for expanding P

[Christian P. <cp...@se...>]

Am Sonntag 19 Dezember 2004 14:38 schrieb stephan beal:
> 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.

This should already work. Have a look into  'demo/process.cpp'.

> - 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.

Would you like to implement argv parsing into the experimental code base?

> - 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.

For accessing process environment, a simple ProcessEnv class exists.

> - 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...

UI things (text and graphical), until now, we're not important for us.
I used the framework for programming server software for a Bank in Berlin, 
Germany. Only UI that the server software got, was a telnet interface ;-)

However, this should change and i would like to see an Toolkit-independent, 
plugin-based GUI infrastructure for P.

> - 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.


Regards,

Christian