OCS-Webclient part 3: Technical difference between OCS-Webclient and the CWA

Besides that our OCS WebClient is functionally different, there are also differences in the way the application is set up.
As the OCS-WebClient matures I come across some problems relates to working in a browser-environment.

• Every additional function needs an environment (functions and storage)
• Handling multiple chatsessions and redirecting flows of conversation.
• Security issues / browserindependancy

Of course the "Microsoft Office Communicator Web Access" Client deals with these issues. It is always re-assuring to have proof that something can be done. These issues were present from the beginning, but as the project started as an experiment and a way to develop my skills in both UC and JavaScript. There are two major differences between my project and "Microsoft Office Communicator Web Access":

• No permanent datacontainer: The probable environment for our project is a portal(in this case Sharepoint) The user probably request multiple pages. If this happens all information used by the OCS-WebClient gets lost. This includes Chatwindows, because they are 'children' of the web-page which can't communicate and act by themselves. The web-access client resides in a seperate browserwindow, in this way it has a fairly solid base.
• Direct contact on the UCWA-Server: The webpage is located on the same server as the web-client. For the basic handling it shouldn't be a problem accessing the webservices on another server. That is, if you don't mind security. Cross-domain scripting is disabled in the standard security settings in Internet Explorer and Firefox.

The last topic will be discussed another time. The solution is to make a proxy-server, or to configure your browsers security level for the main site.

So how do we deal with this problems? Every time the user navigates to another page most information has to be regained. So what about storing information elsewhere? Storing on another server is out of the question. That would compromise the whole idea of having a fast lightweight clientside script. The way to store localy within a browser is a cookie. But cookies can store limited information. We only store that data, so we don't have to login everytime.(Being SessionID, RequestID, AcknoledgementID and the authorization Cookie)

In choosing a client we could make an analogous comparison with getting something to eat while on a trip:

• perhaps the Microsoft Office Comunicator 'rich' client being a restaurant or at home: a lot of choice with all facilitations, but not available everywhere.
• With the "Microsoft Office Communicator Web Access" being a snackbar, can be found on almost every corner, Functional, ready to use but missing some luxuries.
• And our web-access client being a picnic basket. You can have a bite at the very spot you are standing. And you only brought exactly the things you like. But if you want a complete meal, it has to be set up every time you move. You can make it extensive, but your browser has to carry and deploy the basket. Usually this is so fast that you won’t notice it.

My advice : Make a combination of all three according to your taste and mood and eat all you want. Feedback is always welcome.