[Kst] JavaScript from the command line.

[George Staikos]

On Saturday 26 November 2005 22:09, Barth Netterfield wrote:
> Imagine we want, from the command line, to tell kst to load bolocheck.js,
> and pass it the parameters <datafile>, <filterfile>, <first frame>, &
> <nframes>. There are a few options on how to do this:  (Just skip to #4 for
> what I think is the best idea, if you don't want to read read my stream of
> conciousness planning)
>
> 1) all unknown options are passed on to extentions to use however the
> extentions want.
> so: kst -J bolocheck.js --jdata data.dat -jfilter filter.dat --jf0 1121
> --jN 20000
> 	+ Max flexability: the extension can chose any naming scheme it wants
> 	- We lose error checking on command line parameters
> 	- nothing to garantee there there are no parameter collisions between kst
> and various extensions

   And we also lose --help

> 2) Specially blessed extensions (like javascript) get parameters added to
> kst, which get passed onto the extension iff the extension is loaded, and
> ignored otherwise
> eg kst -J bolocheck.js --j1 data.dat -j2 filter.dat --j3 1121 --j4 20000
> 	+ keep checking of command line parameters
> 	+ no parameter collisons
> 	- only blessed extensions can get parameters: third parties can't add
> parameters for their extensions.
> 	- extensions have no ability to run time set parameter names (hence --j1
> etc)

   I think this is worse than #1.

> 3) Registered extensions get a single string parameter which gets passed
> onto the extension unparsed.  The extension must parse it.
> eg kst --js "bolocheck.js -d data.dat -fd filter.dat -f0 1121 -N 20000"
> 	+ keep checking of kst command line parameters
> 	+ extension parameter name space is completely isolated
> 	+ no chance for parameter clashes
> 	? can extensions report parse errors of their parameters?
> 	- only blessed extensions can get parameters: third parties can't add
> parameters for their extensions.
> 	- the "" bracketed parameter names seem kind of funny.

  The funny thing is that we can't register extensions until after parsing the 
commandline. :-)

> 4) parameters starting with --E are stored as a string, like #3, for use by
> extensions which decide they understand them..  (technically, we do this by
> pre-parsing argv before passing it off to KCmdLineArgs)
> eg:  kst --Ejs "bolocheck.js -d data.dat -fd filter.dat -f0 1121 -N 20000"
> 	+ keep checking of kst command line parameters
> 	+ extension parameter name space is completely isolated
> 	? can extensions report parse errors of their parameters?
> 	+ third parties can't add parameters for their extensions.
> 	- no promise that extensions won't introduce parameter name clashes
> between themselves (but if they only chose to recognise special cases, this
> should be OK)
> 	- the "" bracketed parameter names seem kind of funny.
>
> What do people think about option 4?  Can anyone think of a better idea?

  It's probably the only choice, I think.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/