Talk:OLE Client Specification

There are several questions left unanswered by the original OLESpec document. If you have knowledge of WIMP messages in general or the OLE protocol in particular, please give your informed opinion. Don't forget to indent your replies with a colon (:) at the beginning of the line (more colons for deeper indents) and sign with four tildes (~~~~) which will convert into your name and a time stamp. Newer issues should be added at the top, after this text. -- Erik G 20:59, 29 January 2009 (UTC)

Format 2

The whole point of the format 2 (re-edit) type of OLEOpenSession message eludes me. It does not give a file path. Assuming the session number given by the client is of an older session, presumably the server still knows the file path that is associated with this session number (if the file still exists, which would be a bad idea), or still holds the data internally. For open sessions, this is obvious. But if the session is still open, there is no need for an OLEOpenSession message.

Does this mean a server should remember all sessions it had in the past and were closed, only to be able to re-open them when a format 2 message comes in? What about sessions closed on the order of the client? Even if the client closes them because it shuts down? How could a server distinguish between a session that is definitly closed and a session that may be re-opened later? If it can't, must it remember all sessions, forever?

Under what conditions would a client send a re-edit request? Does it write new data to the same location on disk? If so, is it not easier to simply start a new session? If it does not, is the old file still on the disk for the server to read? Why was it not removed after the client got an OLECloseSession message? If it is not on disk in the same location, where should the server get its data? Should it remember all data from all closed sessions perpetually? The mind boggles.

-- Erik G 20:59, 29 January 2009 (UTC)

Window handle and X,Y offset

The OLEOpenSession message contains the following fields:

+36 window handle of display holding file
+40 x offset of data in window
+44 y offset of data in window

What is this for, and should all clients and servers use this data?

My guess is that it is a vestige of a grander idea of OLE that is still in the protocol, but is hardly used. I imagine the client would supply this info so the server would not only be able to edit the data, but could actually handle the redraws of the bit of the document indicated by the info.

Or maybe it is something else. In the Impression help system pages on OLE, there is a mention of the "embedding" phase:

Impression will accept a file of any type to be dropped onto a frame. If it is 
recognised as one of the above [Draw, Sprites, ArtWorks, Equasor, TableMate],
or any file type that follows the OLE conventions, it will accept the data and
embed it within the document, and display a representation of the data.

The handle and x,y offsets might be those of where the file was dropped into a frame. But what would a server do with this information?

Unless some practical use of this information is shown, I think we can safely assume that a client need not fill in these fields (setting them to zero is probably very safe).

-- Erik G 20:59, 29 January 2009 (UTC)

Saving to a different path

The OLEFileChanged message allows a format 0 variation, where the server has written the data to a different file than that created by the client. This raises several questions:

• Will the server only ever write to one other path, or can it create a new file for every OLEFileChanged message? If the latter, this would raise the problem of when the client can delete these files. Presumably the server will hold the data internally until the user closes the window and the server sends an OLECLoseSession message. So the client should then read the file given in the OLEFileChanged message and delete it straight away. If it did not, it would have to keep a list of all temporary files associated with the session and delete them after the session is closed.
• With the format 0 message, there will be at least two different temporary files: the one created by the client and the one created by the server. When should the client delete the original file? Must it wait until the session is closed? Can it be deleted after the first OLEFileChanged message? And (tying in to the #Format 2 re-edit problem, must it keep the temporary file indefinitly (until the client quits)?

Keeping temporary files around for a long time increases the chances of them staying behind after a crash and cluttering up the file system, and is probably a bad idea. See also #Temporary file deletion

-- Erik G 20:59, 29 January 2009 (UTC)

Cryptic original text

The original document contains the following cryptic text, near the end at point (4) right after the description of Message_OLECloseSession:

Note, the client can send this message to a client or broadcast it to
all clients when sessions are being closed from the clients end. (ie
the user is closing the application down or removing one of its
documents).

I was completely puzzled by this gibberish. A client sends a message to a client? Or broadcasts it to all clients? Presumably one or more of the words "client" should read "server". The only sensible combinations are:

• The client can send this message to a server or broadcast it to all servers...
• The server can send this message to a client or broadcast it to all clients...

As the text just before this talks about the server sending this message to the client, the first interpretation is probably the best one. Yet there is no clarity about what the author intended.

-- Erik G 20:59, 29 January 2009 (UTC)

Broadcast or direct

When a server or a client shuts down, it should send a message to each client or server it has a session with, so that the other side can drop the session. The program could either go through the list of partners it knows about and send each an OLECloseSession message (with a session number of -1), or simply broadcast one message. Which is better?

• Is there a performance penalty for broadcast messages? I can imagine such a message needs to be presented to every single task, forcing many taskswitches. If so, sending individual messages is probably better.
• On the other hand, sending a broadcast is probably the safer bet. In situations where data structures have become muddled, or sessions have been forgotten about which should have been remembered, a broadcast will make sure every partner gets the message.

In the extreme, a client or server would not even check if it has or ever had an OLE session, and simply broadcast an OLECloseSession message when it shuts down.

-- Erik G 20:59, 29 January 2009 (UTC)

Temporary file deletion

See also #Saving to a different path. At what point should the temporary files created for this protocol be deleted? The original document suggests that the server should never delete such a file:

Note, the server should not feel it owns the file and thus should not
attempt to delete the file during emergencies.

If the client is responsible for the deletion of the temporary files, at what point should it do so? On the one hand, files should not be deleted when they still may be needed. On the other hand effort should be made to prevent temporary files from being left behind.

It looks like the client can delete a file it created at least as soon as it gets the first OLEFileChanged message. If the server reads the file as soon at it gets the OLEOpenSession message and before relinquishing control with Wimp_Poll, the client can even delete the file when it gets the OLEOpenSessionAck message.

A different matter is the files created by the server, who's file path is passed in an OLEFileChanged format 0 message. Idealy the client can receive this message, read the file and then delete it.

• Are there reasons to keep the temporary files around longer?
• Can the original file be deleted as soon as the OLEOpenSessionAck message comes in?

-- Erik G 20:59, 29 January 2009 (UTC)