Sametime Proxy. A quick introduction based on our experience.

We are currently rewriting our product IM-Support from the old Sametime Links to Sametime Proxy.
We do this for a couple of good reasons, all of the concerning the jar file dependencies:
1. We need to bother with signing the jar files ourself every time we make an update.
2. Even then, the first time the user visits, they will get a un-nice pop-up asking if they trust the signer (suspicious people here would click no, which will make our solution not work at all :'( )
3. Java's virtual machine was a fantastic step towards rich web experience when it first came out, but with the introduction of iOS, Android and the like, loading a jar file in a web page is simply a no go today.

The new STProxy way gives you three choices of interacting with Sametime on a web page ;
DOJO-Widgets, Base component and REST API. What to choose?
As all other choices in life, I will say, it depends on your situation and needs.

DOJO-Widgets:
Easy to use, easy to embed, hard to control.

These are premade chunks of code that allows you to "embed and forget". You almost just add eg. a <div dojoType="sametime.Awareness"></div>, and an awareness block pops up on your html page, where you can change your status.
The same nice small widgets are available for live names, chats, whole web client, business cards etc.
The problem here is if you want to have control over the chat flow, ie. intercept certain parts of personal information, or make other things on the page react to certain messages.
But if you just want a chat on your site, or an indication of whether or not a certain employee is online, then this is definitely the way to go!

Base Components:
(not quite so) easy to use, time consuming to embed, easier to control (once you learn your way through the API)

Since we have developed our own user interface (UI), we didn't want to let go of all the "handles" that the old STLinks gave us. So for us, this is the way to go.
The Base Components is a wrapper around the REST API, and provides an easier way of communicating with the Sametime server without using IBM's Widgets.
The documentation states this about the Base Components (going bottom up, from REST to widget):
"The next layer up is the API referred to as the Base Components. These are a set of JavaScript classes that simplify the interface to Sametime, providing all of the features of the REST API in an much more easily used package. This layer is deliberately kept as lightweight as possible. However, while all of the communications functionality is made available, the Base Components do not provide any user interface functions. These are discussed in Chapter 3."
A thing to remember about the Base Components is that this statement is not quite true; while you cannot use the Widgets, the Base Components can still trigger a widget pop-up to be displayed.
This is quite a hurdle to come across, and I will be posting another entry on the Base Components themselves in a little while.
But with Base Components you now have all the controls you need, by either connecting to the standard methods of Base Components, or by simply replacing them.

REST API:
With the REST API, everything is on you, even the hard work:).

REST is basically just an API on the server. Both Base Components and the Widgets use REST under the hood for communication.
While it is always nice to have several ways of doing the same thing, I can only imagine very limited usage of the bare and naked REST API.
By going directly down to the core of the communication, you have total control, and you therefore have the possibility of implementing only the functions you need, and therefore minimising the load time of the client.
The downside is that you really need to do everything yourself; Sending the AJAX calls to the chatserver, managing the HTTP long poll (also known as BOSH), GUI etc.

I our particular situation, the choice fell on Base Components. It gives us the right balance between control and ease.
What you shall choose, depends deeply on your demands for the implementation, but i hope that you gained a little more knowledge on the topic after reading this entry.
A big thanks to Carl Tyler for his blog posts, and endless answers on developerWorks.
:)
-Sofus