Re: PIPI (Parsed Input Process Initiator) -- another silly proposal?
On 28 Jul 2000, Brian May wrote:
> ie, your example seems to imply that it is specific to input streams,
> and I gather might have similar problems lots of programs seem to have
> these days with command line processing.
>
> If you are redesigning command line processing in such a way, I think
> you should really work to get rid of all existing problems, not just
> one or two.
>
> For, an example of a typical problem programs face. Each program, when
> interpreting the command line must decide "is that argument a option,
> a parameter to an option, or a filename"[1]. If the program gets this
> wrong[2], and mis-interprets a filename as a command line, or vice
> versa, it could result in a security hole (eg if the list of files
> comes from an untrusted source). Not to mention user mistakes...
(Hey. Please, tell me what am I not explaining properly!) This project
SOLVES this problem(s). A core programme would not deal with any:
1. files
2. network sockets
3. other data streams
4. command-line arguments
5. UIs.
All a programme will do is REQUEST FOR ITS NECESSARY PARAMETERS. They will
be passed to it in the most convinient way for the programme to use them
(e.g. binary). My idea is based on the fact that every programme needs
certain data at certain moment to fulfil its task. Imagine how easy is
then to write A UNIVERSAL COMMAND-LINE USER INTERFACE! Moreover it's your
right to modify it to taste for your programme. And now imagine a uni GUI
and a uni ncurses-like UI! There is the place for e.g. an XML definition
of the UI. As I mentioned in my previous message all output format
incompatibilities will be a matter of writing the appropriate filter. As a
matter of fact I developed this idea to implement it in
multi-computer data processing and then realised it could have much wider
use.
> and transfer this information to the program using some really safe
> protocol, that is yet to be invented. So, people who want the existing
> command line method can still use that, or people who want the GUI can
> use that, too. At the same time, better protocols for input can be
> designed and implemented (eg Pavel's suggestion).
In fact I have a not-half-of-a-complete draft of a protocol for network
piping. However, as I am on my own, I could not make it all at once and
decided to start with the PIPI and then extend it in a client/server
fashion.
Hope you could understand me and start giving me valuable comments I need
so much (or otherwise, maybe I should go to me English teacher and to
phsycoanalyst for a test:)),
Pavel
Reply to: