>Sorry, I was far from clear. I didn't mean to suggest that a proxy
>server approach was the way to do this, but mentioned it to show
>that CGI is a rational choice for the browser <-> extension interface.
>That is, I see it working like this:
>
> browser get's protocol it doesn't understand
> it builds up all the CGI environment variables etc. and
> forks off some program to deal with it
> program does whatever is necessary and communicates back
> in the standard CGI ways
>
>No servers and no internet necessary.
Ah, now I understand. It's easy for me, as one who really doesn't write
code (just prototypes) to appreciate the idea that client CGI is preferable
because one API is better than two... but I'd also like to hear if there
are other opinions. For example, is there overhead associated with
implementation of client CGI (memory footprint, CPU cycles) that will make
it less practical on desktop PCs than a PPC/IPC approach (DLLs, OLE,
AppleEvents, etc.)?
Or perhaps should there be both -- leverage the CGI work with client CGI,
but also have a lower-level API for environments where memory and speed are
at a premium?
But what I'm really after is -- am I asking the right questions?
Nick
--------------------------------------------------------------------------
Nick Arnett "We are surrounded by insurmountable opportunity."
Verity Inc. -- Pogo (Walt Kelly)
narnett@verity.com