|
Ok, my turn for the mammoth list of bugs and comments. Some of these have
already been pointed out by Stan
Letovsky.
API Bugs
- You cannot tell from the result of
MCCISendAnchor
whether the callback has been added-to/removed-from the internal list of
callbacks. For example, MCCI_NETWORK_ERROR can be returned
before the callback is added (because the port was not connected) or after
(because MCCIGetResponse fails). A similar situation exists
for MCCISendOutput and MCCISendOutputStop.
-
MCCISendAnchor disappears off into an infinite loop if
you attempt to remove a non-existent callback function.
- At the moment you cannot add the same anchor callback to the same
MCCIPort with different data arguments.
- Ok. Not sure if this is a bug or a feature. Currently you cannot
register multiple output callbacks for a single MIME type. If this is the
intended behaviour, then I think that the API
documentation should be made a bit more explicit.
- Currently the API does not cope well with interrupts. I've created a
patched
version of connect.c which will retry after an interrupt, but
I've only tested it on a Solaris box.
- The debug
printf in
MCCIHandleAddOutputshould go after the test
for NULL otherwise the client can crash under certain
conditions.
- Loads of debug
printf statements still compiled when
DEBUG not defined - not that anybody switches them off yet!
(Also pointed out by Stan
Letovsky.)
-
NetCloseConnection is called directly in several places
in connect.c. If a network connection is broken in this way the
close callback registered with MCCIConnect is never called.
API Documentation
- In cciClient.c the comment on
MCCISendOutput
states
"... The cci client is repsonsible for freeing the
area allocated in the data field ..." This should also
be stated in the API
documentation (I restrain myself from commenting on the spelling :-)
- The code for
MCCIDisconnect allows you to pass a
NULL closure callback which will have no effect. This is not
stated in the API
documentation.
- The CCI library is well behaved and copies strings such as the
mimeType passed to
MCCISendOutput. However, it
would be nice if the documentation stated this (saves having to walk the
code :-)
- The order in which multiple anchor callbacks are called needs to be
specified.
API Suggestions
- It would be nice if
MCCIInitialize was safe to call
multiple times.
- For consistency with the other constants
MCCI_OUTOFMEMORY should probably be
MCCI_OUT_OF_MEMORY (niggle, niggle).
- Again, for consistency, having separate
MCCISendAnchor
and MCCISendAnchorStop routines (to match
MCCISendOutput and MCCISendOutputStop) would
nice. (Also pointed out by Stan
Letovsky.)
- A routine to open the connection specified in
$HOME/.mosaiccciport would be nice. People will want to do it all
the time.
- A decent error code from
MCCIConnect would be a good
idea. (Also pointed out by Stan
Letovsky.)
- Support the
DISPLAY request. This is a mind-numbingly
useful request and I would really hate to see it disappear from the
protocol. It looks like Mosaic already supports it so it shouldn't be too
hard to add to the API.
- Currently
MCCIGet waits until the browser has fetched
the specific URL. IMHO it would be preferable for MCCIGet to
register a callback which is called once the URL has been fetched. Perhaps
have two functions. One that waits, one that does not. (Also suggested by
Stan
Letovsky.)
- We need more informative error codes (or at least, a better
description of the current ones). For example:
- Are all
MCCI_NETWORK_ERROR errors fatal, or does it
make sense to retry on some of them?
- What is the difference between
MCCI_FAIL and
MCCI_REQUEST_FAIL?
- Why does
MCCIGet return MCCI_OK even if
Mosaic was unsuccessful in accessing the URL?
These are the first that come to mind... I'm sure their are more.
Mosaic Suggestions
- It would be nice if there was some kind of visual feedback in
Mosaic when a CCI connection was made. Currently we only get
feedback when Mosaic starts/stops listening for CCI connections.
Indeed, some general feedback when a CCI connection is being used
would also be a bonus.
- Mosaic needs to support the
OUTPUT NONE request
(pretty please).
- It might be nice to have a command line option which
stops Mosaic listening for CCI connections (in
cases where Mosaic would normally start listening by default - when the
cciPort resource was set for example).
- Mosaic should probably remove the .mosaiccciport file
when it exits.
- It would be nice if Mosaic had finer control over the CCI
connections. For example, the capability to terminate individual CCI
connections rather than just the global start/stop listening option
currently present.
Protocol suggestion
- We really need some form of authentication on CCI connections -
otherwise people are not going to use CCI because of the security/privacy
issues (especially when
POST is implemented). I suggest the
addition of a CONNECT request, something like:
CONNECT
Type-Length: (length of authentication type)
...authentication type...
Code-Length: (length of authentication code)
...authentication code...
The CONNECT request tells the browser that a CCI client wants to talk
to it on a specific port address. If the browser does not accept the
specified authentication data, the connection with the CCI client will
be terminated.
Adding the above, and a simple plaintext (yuch) cookie type system
would be a fairly trivial addition. Anything not
involving plaintext would be even nicer.
- The protocol spec should perhaps include a description of the
preferred scheduling algorithm used when handling requests from multiple
clients.
- As I mentioned in my comments on Stan's suggestions I think it would be nice if you had
control over how documents sent to CCI clients are displayed in the
browser. My solution would be to extend
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.
- It would be useful if the
DISPLAY request had an
OUTPUT NONE option. This would enable different CCI clients
to communicate using the browser as an an intermediary. For example, if
client A asks for output of type x, then client
B could send information to A by doing
DISPLAY OUTPUT NONE
(info of type x)
- What about some additions to the
SEND ANCHOR request
to:
SEND ANCHOR [SCHEME <scheme>] [RETRIEVAL {ON|OFF}]
SEND ANCHOR STOP [SCHEME <scheme>] [RETRIEVAL {ON|OFF}]
This message registers an address for activated URL anchors to
be sent to. This registered address is intended to remain
active until a SEND ANCHOR STOP message is sent.
If <scheme> is specified, then only URLs of that scheme are
sent. The effect is cumulative, so doing:
SEND ANCHOR SCHEME news
SEND ANCHOR SCHEME html
would cause all 'news' and 'html' URLs to be sent.
If <scheme> is not specified all URLs are sent to the
client.
If RETRIEVAL ON is specified then the browser should retrieve the
specified document and then send the URL to the client. If
RETRIEVAL OFF is specified the document is not retrieved and the
browser just sends the URL to the client. If neither is specified
the browser defaults to RETRIEVAL ON.
Output from the browser to the specified history port will be:
301 ANCHOR <url>
General
- Currently closing a CCI connection from Mosaic or the CCI client
leaves sockets hanging around waiting for shutdown acknowledgements.
Something wrong somewhere.
- As pointed out by Roman
Mitnitski it would be very nice if the current implementation
supported file based sockets.
- As Stan
pointed out
SEND should be supported properly -
Mosaic and the API should support multiple connections to a single
CCI server.
- I also agree with the comments
Stan made on the lack of
POST in the API. However
I would not want to see this implemented before
some form of authentication system was added to the CCI protocol
since it opens more security issues.
- There should be a CCI server library to enable other browser authors
to add CCI to their programs relatively painlessly.
As usual, comments and abuse welcome :-)
Adrian
|
More CCI Bugs and Suggestions 
