Monthly Archives: August 2007

Not Cut and Dry, Cut and Paste

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).

  1. Open Word or similar on local machine
  2. Insert a bunch of pictures (clip art or photos) with some text.  Ten big photos will probably do.
  3. Select all and copy to clipboard
  4. Switch to your server session and start Word or similar
  5. 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 :)

Aggregate Computing

Aggregate computing has existed in various forms over the last 50 years.  It usually lives within the realm of the bigger systems and is focused on high power jobs.

IBM built a model around its mainframes that made everything virtual (VM 360) that basically meant that the software had no idea how the hardware was actually running.  This is a huge generalization, but essentially true.

My translation is that aggregate computing allows for collecting resources from different parts of the network and building a greater whole.  Some would call this distributed computing but I’m really only focusing on one aspect of it.

What I would like to see happen from a Citrix point of view is to have it so the client and server form a tighter relationship.  The long term goal is to have the two systems act as one from the user’s perspective.  There are a number of challenges to overcome to make this happen but the end result will give the user a more powerful system which uses the best available resources to do the tasks at hand.

In the much longer term, it would be possible to expand this relationship between many machines until you had basically formed a computing environment which is much more powerful than what an individual user would have access to.

The idea is to bridge between the systems and tear down the barriers between different platforms.  It is idealistic but it is where things are going.

As an example of this (even though perhaps not the best), it would be possible to combine disk resources for the user.  A C drive on the server could be merged with the client.  Rules would apply to how things were merged but the user would see a fairly decent mapping of what was available for a combined C drive.  This solves the problem of client drive mapping (with drives not matching and being where expected) and also provides a way to gain access to data and programs in a more natural way.  The same could be done for other resources (like the registry).  Obviously it is early to be talking about this with regards to Citrix.  It is an idea that has been floating around for a bit and it seemed like a good time to get it out there.

What I imagine is that collective model would present a view to a broader system view.  It is kind of like saying that we could build a virtual desktop that is built upon potentially multiple real desktops.  This means that the collective power of these desktops could provide a very heterogeneous range of applications.  The key concept shift is that this applications would appear to be running native when really they could be running anywhere in the world.  The other key point is that they would all think that they really are running on the same desktop.   All the resources could be shared between the different desktops (within reason).  This idea is a step closer to getting Citrix to embrace distributed computing.

What I would like to convey is that this idea is very raw.  It would be great to hear some feedback about what this idea means to you.

Potentially this kind of reasoning could help shift the logic of where CPS and CDS are going.  In many ways, Citrix has been attempting better integration for years by adding more features to work between client and server.  What is missing is the leap towards understanding that the two systems should be merged under one virtual umbrella.