Posts Tagged ‘session management’

Does HTML5 mean the end of the road for Gears, HTA and Flash?

March 10, 2011

Web standard HTML5 contains loads of great features, from video playback to drag-and-drop. But the best bit, and currently one of the least talked about elements, might be the capability to run apps offline.

The normal web experience is hindered by connectivity. Users can typically access web apps while they have a connection to the internet. Once offline, individuals lose access to email, calendar or notes. There are, of course, workarounds. Google Gears, for example, allows users to navigate compatible sites offline and synchronise when back online.

Microsoft HTML Applications (HTA), meanwhile, is a Microsoft Windows formalisation that provides a web-like experience offline. And Adobe Flash can also be run offline, allowing users to run Flash-based content.

Such workarounds are OK but they are also a bit messy. People want the same experience online or offline; they want to get hold of – and manipulate content – regardless of location and they don’t want to be hindered by platform specific technologies or plug-ins.

HTML5 provides that standardisation. Its two–pronged approach re-connects the user through an SQL-based interface for storing data locally, and an offline cache that helps ensure apps are always available (see further reading, below).

With regards to availability, HTML5’s application cache mechanism provides the ability to have a fall back page for rendering pages when offline. It also provides a means to update cache dynamically. The key, here, is client-side management.

And without wanting to bang my own drum too loudly, it is a rhythm I have been hinting at for a long, long time. I blogged two years ago (see further reading) about client-side management as a method for keeping data in the browser, rather than the server, and as means to reducing memory and processing requirements.

“If only it was supported as standard by the browser rather than having to use hidden fields,” I concluded – and now that day is fast approaching. HTML5 creates a standards-based method for creating local apps that run offline.

As mentioned earlier, HTML5 also provides the ability to store data locally through a client-side SQL database. A series of apps could potentially work with this database, providing a new level of accessibility and integration.

The total approach represents a huge step forwards for web development. It also signals that the end is nigh for proprietary workarounds like Gears, HTA and Flash. HTML5 is the future and web developers simply must get with the program.

Further reading:

http://www.w3.org/TR/offline-webapps/

http://blogs.computerworlduk.com/facing-up-to-it/2008/07/client-side-session-management/index.htm

Wake up to the power of the web browser

May 11, 2009

Are you still using the desktop; still choosing to access enterprise applications through Windows?

It can be difficult to break away from accepted ways of working. Managing such a break is even more complicated when the business is bamboozled by a series of marketing buzzwords.

The big hype of the moment is cloud computing, a generic term used to describe the provision of scalable enterprise services over the web. Rather than having to access applications through a traditional desktop interface, businesses can use the cloud to host applications and store data.

As many as nine out of ten C-level executives know what cloud computing is and what it can do, according to a recent survey by consultancy Avanade and Kelton Research (see further reading, below).

But at the same time, 61% of senior managers are not currently using cloud technologies. For the majority, it is probably time you woke up to the power of the web browser.

Working through a web browser is no longer a niche activity. Salesfore.com and Google Apps are high profile and popular examples of how users can access applications through a web browser.

Such cloud-based software suites mean users can enter the browser and work collaboratively on essential documents. The high quality of services also means users can also benefit from the functionality of traditional desktop software, such as drag and drop, and multiple interfaces.

There are still issues to overcome, of course. Some businesses remained concerned about hosting information outside the corporate firewall. And recent problems with Google Mail show how failure of the cloud could derail essential business processes.

Such issues mean providers will have to develop secure methods for accessing browser-based applications offline, as well as online. However, such problems are minimal given the quick development of cloud computing.

Businesses often need a high profile sponsor to help push new technologies. When it comes to browser-based apps, there can be no more prestigious supporter than Vivek Kundra, the new CIO of the United States and a confirmed fan of Google Apps (see further reading).

What’s more, the recession is likely to push interest in cost effective and hosted applications. The Avanade and Kelton research also found that 54% of executives use technology to cut costs.

In these economically sensitive times and with an increasing high level of functionality, the web browser can help your IT department provide a great customer experience.

Further reading

Cloud computing is a two-edged sword
http://blogs.zdnet.com/Gardner/?p=2841

The new US CIO is a fan of Google Apps
http://blogs.computerworld.com/obama_cio_vivek_kundra_white_house_cio

Client Side Session Management (part 2)- Sharing is good

July 31, 2008

In my first article we covered the issues of server side session management and the benefits from a server perspective of session data being managed client side within a browser. These benefits are mainly technology related, but what about the user benefits? Yes faster more responsive applications can be achieved with client side session management, but from a user perspective the ability to share data across applications would be very powerful indeed.

The concept of being able to share data across disparate applications is not new, indeed as a windows programmer I’ve gone through the journey of DDE (dynamic data exchange), OLE (Object Linking Embedding), COM etc… However windows also had other mechanisms such as Global Atoms (anyone remember those ?) as well as traditional approaches like local databases or files.

However a browser based model is more difficult because of the sandbox security model. A server based solution does exist in the Java world this is the area of WSRP and Portlets. WSRP allows portlets to publish data to other portlets using standard interfaces. So if you had a window with a directory of your contacts listed, you might click on a name and your other windows (portlets) would respond by bringin back data about the person you clicked on.

Again however, if only browser developers would open their eye’s to client side session management, we could have very dynamic applications WITHOUT portlets and the server side overheads associated with portlets. (Remember a portal view of 5 portlets, means 5 times the number of sessions being managed by the server – hmmm you thought you had redundancy and performance licked until you deployed portlets ;o)

So how could this be done? I’m sure there are a number of ways, but if it’s been done before and worked well then I’m all for plagarising. Global Atoms ;o) Basically you should be able to define a global variable and provide a publish/subscribe model for that data item. This then would allow you to share data across browser applicatons (a bit like Google auto fill, but with application definable fields).

 The consequence? We reduce carbon footprints whilst creating more dynamic applications.


Digg!

Client Side Session Management…

July 18, 2008

Ok this is an old hobby horse I’ve reeled out many times, and now that I’ve got round to starting a blog what better place to find a permanent home for this old equidae.

The traditional way of managing sessions is on the server with the application container managing session keys/data. As a front end developer your job is simply to populate the session data as it is capatured on screen, the application container does the rest for you. The application container should offer different mechanisms for replicating session data across servers, thus providing session failover. It should also optimise the storage of the data itself, and manage the session keys with it’s own policies for clearing out dead sessions.

The problem with this model is that it is simply not that easy. Some of the issues that need further consideration are: Memory optimisation, Long vs Short Running sessions, Server Redundancy:

When storing data in sessions, the data element is normally given a name, generally this is something meaningful that a developer can use to make code more readable. However these name themselve take up memory. Whilst this may not seem a huge issue with the amount of memory in servers these days, we’ll see later in the post why optimising memory for sessions is necessary. So one improvment you can make is to implement hashing to reduce lengths of names used in code. Another technique would be to use compression for the actual session data especially for large free text fields.

Generally there are two types of sessions long running or short sessions. Typically internal applications such as call centres will have users that log-in in the morning use an application all day, and log-off at the end of the day. Such applications if not designed efficiently often do not release session data during the session, this can have the issue of builiding up huge memory requirements per user of the application. Prior to memory depletion, performance degradation will be the first issue as memory is swapped in/out of disk, followed by out of memory server crashes. Hence developers need to consider what memory should be held and when to release this memory. Short running sessions with mass users e.g. shopping sites, tend to have less per user storage requirements but many more users, creating a large memory requirement overall. In this scenario identifying dead sessions is paramount to reduce memory redundancy. Other optimisations include identifying session data that is used not per user but globally across all sessions, and caching one instance of that data rather than load it per user.

So it is for reasons like the above why client side session handling make so much sense, if only it was supported as standard by the browser rather than having to use hidden fields. Quite simply client side session management is a means of keeping data in the browser rather than on the server, therefore reducing the memory requirements and extra processing that an application container has. It would not only reduce the cost of the server you’d need it would also improve performance of the client application also, more so than the use of Ajax.

I can’t think of any downsides to this approach whilst the upsides are huge. What do you think?


Digg!