Vargas Software Development

One of the few commands that ClipboardLAN protocol includes is the VERSION command. VERSION works like this:

> VERSION
101 Current protocol version follows
2.0.0

This is deadly simple. I could even dismiss the status response, but I put it because I might change my mind so as not to allow this request to be processed if it comes from an unlogged client (currently, it answers unlogged client requests).

However, there is something not that simple: versioning. I deliberate about what versioning scheme I should use. I thought the major.minor.build scheme would fit for this project. Why did I choose this one instead of the others? Because I plan to release often.

In spite of not existing something as THE SOFTWARE VERSIONING METHOD, I think this is the best approach for a project like this. I thought that major version number will represent the version of the protocol, so every compatible ClipboardLAN release will have version 2.x.x. The minor build will increment each time there are major changes in the UI and the build number is just the build by the moment.

Summing up:

• Two different instances could work smoothly if the share the same major number. 2.x.x and 2.y.y works!
• The change between 2.0.x and 2.1.y is an improved UI.
• Build number is not necessarily significant by the moment, but it is there because we might need it someday to specify something meaningful.

I have been reworking the LOGIN command these days. One of the features I have not found in other shared clipboard applications is the possibility of having two or more shared intances in the same subnet. I mean I would like to share a clipboard with my three computers, but my roommate also wants to have a shared clipboard with his two computers, for instance. Okay, this is already possible with the current software but the user must change the port used in every instance. We want to make this as easy as possible, so this is not a valid option. I also saw some share clipboard software which lets you specify the IP address of the other computer. This is okay for me, but it is not what I am looking for. My goal is ease of use.

So then, I thought of a LOGIN command like LOGIN mode auth passwd token where:

• mode is SINGLE or COLLAB. SINGLE is intended for one person and many computers. COLLAB is for two people and two computers (by the moment, although this could change in future).
• auth is PUBLIC or PRIVATE. We will use PUBLIC in public networks (Wireless connection in a hotel or at the university) and PRIVATE for home use (or places where you know who is connected to your network). Currently, this has been added for future improvements, but it does not do anything special.
• passwd is a sha1 hash of the share clipboard name (e.g. Lou’s Clipboard) plus the remote IP address (e.g., 192.168.1.100) as a salt. Something like sha1(“Lou’s Clipboard”+”192.168.1.100″). We avoid collisions in this way as well as we provide some kind of security (if someone is listening and receives this hash, he does not know what is the shared clipboard name so he cannot join).
• token is a GUID. For each request, we send a different token so if we had an answer, we know if it is really and answer or it is just a request.

Let’s see this better with an example:

Alice opens a new connection with Bob
LOGIN COLLAB PUBLIC da39a3ee5e6b4b0d3255bfef95601890afd80709 3F2504E0-4F89-11D3-9A0C-0305E82C3301
Bob accepts this request but waits until Alice accepts his
202 Accepted

At the same time Bob accepts the request, Bob opens another connection in the opposite way
LOGIN COLLAB PUBLIC d0be2dc421be4fcd0172e5afceea3970e2f3d940 3F2504E0-4F89-11D3-9A0C-0305E82C3301
Alice accepts the request.
202 Accepted

Now both of them are clients and servers and the connections have been established. Look at the red text: Bob answers the petition with the token he was given.

Well, I am not really versed in designing protocols with some sort of security, so I would like to listen to your comments and suggestions.

I have just finished a draft with the commands you are supposed to see in the next version of ClipboardLAN. This is work in progress and it may change during the development. However, if you are curious, you can take a brief look at this document. Basically it shows the commands it will use (LOGIN, PING, VERSION, CAPABILITIES, TRANSFER, QUIT) and some of the rules I thought.

During the brain-storming I thought of different schemes to design a protocol and, finally, I decided to use my knowledge of the NNTP protocol to design something alike. NNTP protocol specification (RFC 977) is a must-see for anyone seeking for inspiration. I, personally, found it inspiring because of cultural references in the examples and the way is presented. Besides, it is really easy to understand.

At the moment, I have put most of my effort in the collaborative part of the ClipboardLAN. However, I spot a few cases where lots of people might it found useful: interactive sharing. I mean it really shares the content of the clipboard across a network without asking for confirmation. So I am still thinking about a “MODE” command where it sets the kind of use it will have (COLLABORATIVE MOVE vs. INDIVIDUAL MOVE).

“Collaborative mode” is thought to work in pairs. So connections are between one-on-one. It also ask for confirmation between replacing the current content with new ones. “Individual mode” supposes you are working alone with a few computers, so it just will spread the data to any computer without asking (but I think that this should not be done when large files or data are put in the clipboard because it could time considerable time. I must work on this).

I still have to make some mockups to get a clear idea about how it will work…

These days I have talked with lots of people about these ideas and expectation is rising. I have found some prospective users and I think I am becoming some sort of a vaporware seller. I expect not to. However, I can’t promise you to deliver this on time, because it is not one of my top priorities. But this is my roadmap by now:

March 2009: ClipboardLAN 2.0 for Windows a first beta is being released.
April 2009: ClipboardLAN 2.0 for Windows release candidate goes out.
May 2009: ClipboardLAN 2.0 Windows is available :D

November 2009: ClipboardLAN 2.0 Linux(Gtk) is available.

PS: If this post does not make sense to you is okay. I am just writing these things down as a brainstorm to think about them later.

Sunday morning, I started developing the next major release of ClipboardLan: ClipboardLan 2.0. Since I published the first release of ClipboardLAN February last year, I have been asked for updates from some users who are interested in it. That’s good news!

Why 2.0 instead of 1.1, 1.5 or 1.X (where 0 < x <= 9)?

In first place, because I will rewrite it from the scratch. I will not be working on the earlier code base because it was ad hoc code and by no means it was worth to extend. I know that this is the kind of things I should never do. But hey, I am not a commercial shop so I don’t care indeed.

I will also rework the architecture to make ClipboardLAN totally extensible and portable. I am interested in a Windows version and a Gnome version. So it is essential to make it easy to port. I will also look for some collaboration: extending it must be easy.

What will be the major changes?

Probably, the most breaking change will be the use of P2P and autodiscovery. ClipboardLAN uses web services to work right now. We need a web server and an ASP.NET process to simply pass a snapshot between computers. This is wrong no matter how hard you try to convince yourself. I would like to reach average users, so I cannot expect them to know how to set up a web server. This new version will be as easy as 1-2-3. Just double click the executable (we would not even require an install) and it will automatically be paired with the other computer running ClipboardLAN. Easy, isn’t it?

There will be a complete makeover of the user interface. Currently, there is nothing such as a preview of what is being sent until you replace the contents of the clipboard. In the new version, there will be a preview for each notification so you can dismiss it or do whatever you feel.

When could we download a beta or a release?

I expected to release the Windows version in March 2009.

These are good news, but it sounds like vaporware to me. What have you done so far?

Well, I personally expect it not to become vaporware. I will try to do my best. At the moment, I set up a Subversion repository and created a new bugzilla product on my server and developed some mock ups. Besides I start writing a protocol specification which will be public within a few days.

Why are you doing this?

Because I need it at home and I think it could be of public interest.

Last week I published first release of Clipboard LAN. Clipboard LAN is a little piece of software I developed during January to solve one problem I had: sharing clipboard content between two PCs connected by an Ad Hoc Wireless Network.

You can find source code at: http://www.codeplex.com/ClipboardLan

In the next week, I’ll write a few posts about how can you setup the environtment.