Re: exec.basic - comments please

["Mal Lansell" <mal@xxxxxxxxxxx>]

OK, that makes sense.  I was thinking the pid would be enough, but
it's not exactly human readable ;-)

Mal


--- In ukha_xpl@xxxxxxx, "rleong1" <rleong1@y...> wrote:
>
> looks good. perhaps the status can return the name of the program
as
> well in case you launch more than 1 copy of the same app?  this
would
> make digging through logfiles to debug stuff much easier.
>
> --- In ukha_xpl@xxxxxxx, "Mal Lansell" <mal@l...>
wrote:
> >
> > Following up the talk of an xPLExec application for launching
> > arbitrary executables, I propose the following schema:
> >
> > xpl-cmnd
> > exec.basic
> > {
> >     pid=num       //integer identifier (<2^32)
> >     program=""    //executable filename (without path)
> >     path=""       //path to exe (optional)
> >     path=""       //as many as needed
> >     args=""       //program command line argument
(optional)
> >     args=""       //as many as needed
> > }
> >
> > xpl-stat
> > exec.basic
> > {
> >     pid=num       //same integer as sent in the xpl-cmnd
> >     status=[Failed][Started][Finished]
> >     return=""     //extended info if status is failed
or finished
> > }
> >
> > The pid is a program ID - it is not the same as the Windows
Process
> > ID, but is a user specified number to enable status messages to
be
> > associated with commands from xPLHal without having to match the
> > entire message body.  If only one program is spawned at a time,
then
> > feel free to just set it to the same value every time if you
like.
> >
> > Program is the name of the executable file to run, without any
path.
> >
> > As many or as few (none is ok) Path and Arg elements can be
included
> > as needed.
> >
> > Each Path item must contain only one piece of the path with no /
or
> > \.  These will be inserted by the receiving application.
> >
> > Each Arg item must contain only one command line argument.
> >
> > The xPLExec application will attempt to spawn the executable,
and
> > will respond with a status messages containing either
status=failed
> > or status=started.  If status=failed, then the return item will
be
> > set to one of the following values:
> >
> > "argument list too long"
> > "invalid argument"
> > "program not found"
> > "program not executable"
> > "out of memory"
> >
> > If the program runs fine, the an xpl-stat message with
> > status=started will be sent.  When the spawned program
terminates,
> > another xpl-stat message will be sent, this time with
> > status=finished, and the return item set to the return value
from
> > the spawned program.
> >
> > Windows spawn functions also support specifying a set of
environment
> > variables, but I couldn't see a good way of including those in
the
> > schema, with all their potential oddball characters.  Hopefully
that
> > will not be too much of a restriction.
> >
> > Comments would be appreciated.
> >
> > Mal
> >
>