Assumptions are easy to make. We do them all the time. Usually they help to speed up understand and create a kind of common language. Other times, they lead only to confusion.
The clipboard design is based on one primary assumption. The core idea is that data is exchanged between programs using a common clipboard. One program puts it on and another takes it off. There are all kinds of cool features like being able to host multiple formats at the same time so that programs can take what they understand. This seems very clever to me.
However, there is one major failing point when it comes to taking this data to another machine. With Citrix, it is possible to transfer the clipboard items between client and server and back again the other way. Citrix’s view to this problem is to transport the clipboard data “as is” to the other side.
This is an assumption as well. The thought is that the data contains everything you need to know.
The truth is that this is not always the case. Take the “HTML Format” which Microsoft created for its programs. It’s clever in how encodes the data into essentially a HTML document and puts the images as references. It’s small and efficient at its task compared to the much bigger and awkward “Rich Text Format”. The “HTML Format” works really well for transferring data from web pages. The problem, for Citrix, is that the “HTML Format” cannot be used 100% on the client or server machine from the other machine. It works great for web content but fails badly on clip art or pictures from local resources. The reason is simple enough. The client or server is not guaranteed to get access to the resources it needs to do the whole task. Pictures can be saved in temporary directories for Office but cannot be reached from the other machine.
From the user point of view, all they would see is little red x’s in the places where there pictures should be. Very frustrating, to be sure.
I only learned of this aspect a couple of weeks ago and it lead to a major shift in thinking for PortICA clipboard support. Instead of throwing open the gates to let everything through, we need to be more conservative so that only the formats that are “self-contained” are let through. This means that the data has to provide everything on the clipboard and make no assumptions about local resources being present.
To support clipboard support with all the formats would be a formidable task. It would assume full knowledge of the formats and the ability to translate them across. For example, the “HTML Format” problem could be solved by re-writing the tags to point to resources that are correct and can be viewed from the remote system. The simplest variant of this idea would be as easy as changing the drive letter (assuming that the drives have not been remapped). Basically, there is a need to make sure that the data is managed so that the remote system will get everything it needs.
There is a very wide range of things that the clipboard supports. Such things are OLE object embedding and file lists are used to reduce the amount of clipboard data while still providing value between applications.
If we had a decent solution for remapping file lists, we could potentially support copy and paste of files between systems in a much more fluid way.
There is an idea that using more native clipboard support for files that it would be possible to transfer files much more efficiently than the current client drive mapping model. The reason for this is that we do not need to base the protocol on the existing CIFS style transfer model and would be able to stream the files using the best algorithms possible.
It’s very early to talk about such an idea but it is fun to see what kind of interest there would be in such a thing.
There has been some testing on the PortICA clipboard and it has created much investigation into how things work right now. As an interesting experiment, I suggest you try this (if you have a spare minute).
- Open Word or similar on local machine
- Insert a bunch of pictures (clip art or photos) with some text. Ten big photos will probably do.
- Select all and copy to clipboard
- Switch to your server session and start Word or similar
- Paste
Assuming that you have a slow enough connection (slower than LAN) and big enough pictures, the transfer will take longer than one minute. If this true, I would bet that your copy will fail.
The reason for this will be explained in a future post 🙂
Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide
Red Circle Blog 