|
Having finally finished some rather dull conference preparations I can
finally get back to playing with CCI. Some comments on Stan's interesting
suggestions.
Implement POST
Without it, the utility of the protocol is drastically reduced --
apps cannot send long messages to Web servers. 'Nuff said.
Seconded - but please add some form of
authentication mechanism to CCI before implementing it, otherwise it opens
possible nasties.
Resurrect SEND Ports
The second biggest problem in the current API lies in a crucial departure
from the spec: the SEND command(s) do not register new, additional
ports for app/Mosaic communication; instead all communication goes
through the single port specified via Mosaic's File/CCI dialog.
...
Yes! I agree completely. This absence considerably
reduces the
utility of CCI.
Send Docs to Mosaic AND App
There appears to be no way for the app to get copies of documents
displayed by Mosaic, whether the display was initiated by the user or
by MCCIGet. In the former case, SendAnchor can be used to get the
anchor, but not the document; SendAnchor and Get do not seem to work
well together. In the latter case MCCIGet requires an output argument
to specify whether output is to be sent to the app (output
none) or Mosaic, but one cannot do both without calling it twice,
which is wasteful, since the request must then go all the way to the
httpd server twice.
Since I've not been able to get output callbacks to work reliably (doing
an MCCIPoll crashes Mosaic) this is mostly from a reading of the
CCI documentation.
According to the CCI
protocol when you tell a browser to send you a
specific MIME type
The recipient will then be responsible for displaying the output.
(section 3.4.2). This seems to imply that the browser will
not display documents sent to a CCI client. However, the
comments on the GET request in section 3.1 seem to imply that the
document will be displayed unless the OUTPUT NONE arguments are
passed.
I personally think that the second reading makes more sense (for reasons
which I will explain in a minute) so for a CCI client to force a browser to
display a document and get a copy itself a client should:
-
MCCISendOutput with the appropriate MIME type
-
MCCIGet with an output of either
MCCI_DEFAULT, MCCI_OUTPUT_NEW, or
MCCI_OUTPUT_CURRENT
However, from your comments I get the impression that an interactively
requested URL is never displayed if it is sent to a CCI client. IMHO this is
incorrect behaviour. My reading of the CCI protocol was that a default GET
request should have the same effect as the user requesting the URL - this was
reinforced by the following comment on MCCIGet in the API
documentation (my emphasis): This function instructs Mosaic
to fetch a URL (URI) as if the user had done so.
If an interactively requested URL and a default GET
request are equivalent then the behaviour of CCI makes a lot more sense
(IMHO).
Moreover, I was unable to use Get inside a SendAnchor callback.
I've not had problems using MCCIGet inside a anchor
callback (well, it worked when I tried it five minutes ago anyway).
Suggestion: add a RelayDoc boolean
argument to SendAnchor and SendOutput which if set causes SendAnchor
to send the document as well as the anchor to the app, and causes
SendOutput to send the document to the app as well as (if enabled) to Mosaic.
With the previously outlined mechanism you can achieve the same effect as
having an anchor callback with a true RelayDoc by
registering an output callback with a type of "*/*".
I personally like the separation of fetching URLs (SEND
ANCHOR) and fetching documents (SEND OUTPUT) and think it
should be kept.
The obvious problem with the above is that there is no control over how
interactively requested documents are displayed. My preferred solution would
be to add a control over whether documents sent to CCI clients are displayed
in the browser. Extending SEND OUTPUT like this:
SEND OUTPUT [NONE|CURRENT|NEW] mimeType
SEND OUTPUT STOP mimeType
with the additional arguments specifying the default display behaviour of
Mosaic for that MIME type (this would also override the "default" behaviour of
the GET request). Quite how this would be interpreted if multiple
CCI clients register for output of the same MIME type I'm not sure - I'd
probably go for NEW|CURRENT overriding NONE, and
NEW overriding CURRENT.
Why does Get use SendOutput callback?
SendOutput callbacks are specific to a mimetype;
this makes sense for interactively requested URLs. However
for URLs requested by the app, the mime-type is irrelevant.
I suggest instead that there be two versions of Get.
One takes callBack args and does not block; the
other blocks and returns the document. The callback
procedure for the nonblocking Get would be used only once,
to handle the particular document; it would not handle
a whole class of requests like the Anchor and Output
callbacks, unless repeatedly registered as the callback
for each request. SendOutput should continue as before,
but now used solely for redirecting interactively
requested documents. Also, SendOutput should be able
to notify the app what the URL was; that should be
an additional argument to the callback.
I agree that a non-blocking version of MCCIGet would be an
excellent idea. However, I think MCCISendOutput should retain its
current function and redirect output for documents whether the document is
requested interactively in the browser or by a call to MCCIGet in
a CCI client program. Having MCCIGet return the document would be
wasteful since the CCI client may not always need it.
The reason for keeping the current behaviour of
MCCISendOutput
is that (if only the API supported it) there may be
more than once client connected to a given browser. If CCI client A
requests MIME type X and CCI client B requests a
document of that type, then client A should receive a copy.
IMHO the same logic should apply to documents displayed using the
DISPLAY request (which with any luck will soon be implemented in
the API).
I agree that the ability to locate the URL of a document sent to a CCI
client would be useful.
Noninteractive Port Choosing
It would be useful if Mosaic could
inform launched apps of its CCI port via an environment variable. Also
if the user could specify a default CCI port to Mosaic via an
environment variable and/or command-line argument. Also if user could
specify an auto-port option to Mosaic, via environment variable
and/or command-line argument, which would cause Mosaic to automaticaly
enable CCI on the first available port.
Agreed.
AF_UNIX sockets would also be very nice (hint, hint).
Random
- Why does MCCISendAnchor off need callBack args? Why
dissimilarity in enable/disable between SendAnchor
(on/off arg) and SendOutput (uses SendOutputStop to
disable)?
You need callback arguments when removing callbacks using
MCCISendAnchor to allow you to add/remove a number of different
anchor callbacks to/from a single MCCIPort.
I agree that separate MCCISendAnchor and
MCCISendAnchorStop functions would increase consistency and
clarity.
- Setting interface off on CCI menu option does not disable
the state of the connection -- ie if SendOutput is in effect, it stays
in effect.
It also leaves the sockets in a mess waiting for shutdown
acknowledgements.
- Mosaic can be made to crash due to CCI interaction. This was
happening unreproducibly when MCCIPoll was invoked only interactively;
may have been some kind of buffer overflow.
I've only had this problem when I register output callbacks (see Has
anybody got MCCISendOutput working reliably?). However, if I do register
one a browser crash always occurs.
- If SendAnchor and SendOutput are enabled simultaneously.
only SendAnchor callback is called, but Mosaic does not display doc.
Since you seem to have managed to get output callbacks to work reliably at
least some of the time, then you have got one step further than I have :-)
- MCCIInitialize returns unknown status code.
Well... it doesn't really return any kind of status code.
(Okay, it does return a NULL MCCIPort if:
- You can't get an IP from the host name
- Socket creation fails
- You cannot malloc space for the MCCIPort
- Connection to the socket fails
but this isn't much use.) A decent error code is needed.
- Anchor callback seems to be many times (eg 18) for each anchor.
Not had this one happen to me.
- A number of un-#ifdef DEBUG...#endif'ed debugging printfs in
cciClient.c
Yup. One of them can cause the client to crash too :-)
Right then - That's about it for now. I'm off to put the finishing touches
to my own list of bugs and suggestions. (The CCI developers must really love
us :-)
Adrian
| 
Comments on the comments... 
