KlipBlog.

Ever wonder what the KlipFolio development team is working on at this moment? More often than not, it?s dealing with some detail that hopefully no one ever sees.

Building a platform for intelligent awareness means dealing with hundreds of minor issues. If we make the right design choices, all the complexity is hidden from the developer and seamless to the user.

On of those (rather big) details is to handle double-byte languages seamlessly. Today, KlipFolio already supports over 37 languages.

This is great, true double-byte language support must be seamless. Take the Google news for example. It can show you news in 22 languages, and KlipFolio supports them all in the Klip. That's good. However, in our current Beta B, if you choose the language in the Klip Setup, you don't see the proper encoding of the language in the ListControl.

That's bad. We've just fixed this in the upcoming Beta C. Now, all the Klip UI controls can be created and updated using any of the hundreds of supported codepages and the full Unicode character set.

Now, when the Klip needs to display double-byte characters in a UI control, you now see this

That's good. Lots of things are going on under the hood to make this work seamlessly, and they are all hidden from the Klip developer. Not having to worry about how your application will handle other languages or network connections or XML parsing lets you focus on the important part : your content.

It just works, and that's the way we like it.

Where is the server?

Occasionally, we get asked by prospects `Where is your server for KlipFolio? How much does it cost? They see the rich output of Klips, such as the weather, news, stocks, sports, etc. and would like to put their content on their user's desktops in a similar manner. But they first they want to know the cost of our server and how it creates RSS feeds from their data.

There is no server, we say.

Long pause. The Klip has all the intelligence to access and display the data. There is no server required.

But how does the Klip get the RSS feed? they ask.

The Klip does not need an RSS feed, we reply.

Another long pause. A Klip can read any XML. This means it can read an RSS feed just fine, thank you, but it can read any XML your servers create (including HTML, since HTML is really a form of XML).

At that point, we usually give an example. Suppose in your company has a web-based CRM application that supports 200 concurrent users. Each user has a login screen and password. Trouble is, the CRM information changes so frequently that sometimes agents miss important customer follow-ups. You want the critical CRM information for each agent visible on their desktop as a dashboard so nothing is missed. Well, you must need another server right?

No. Since the user already uses their web browser to login with authentication (and the CRM application is showing them only the data they have permission to see) a Klip can automate this login process. (Our HotMail Klip automates the authentication with Microsoft Passport, for example). A Klip can then parse the XML (including HTML) to extract out the key data for the user. From that point onward, all the built-in data processing and display capabilities of a Klip take over. The Klip now automates the users effort to monitor quickly changing data.

There is no server that needs to 'pre chew' the data so its dumbed-down RSS. The Klip can parse structured data from your existing server, display it in columns, and let each user filter it according to their needs.

There are times when you need a server, such as the data does not exist anywhere on the web. More often, if you can create a simple program that extracts the data and updates an XML file on a web server, then you are done. The Klip can monitor the XML file for changes.

So there is no server to buy. The intelligence is in the Klip.