Thoughts on Structured/Unstructured and Shared Information Management using Wiki and other emerging technologies
Friday, December 09, 2005
Increasing the responsiveness email programs on desktop ...

As I type this, I am waiting for my thunderbird to refresh itself and help me see latest emails from our corporate IMAP server. This is a routine affair: As soon as I open the laptop, most of the hibernated program would have to get loaded into memory, and that often takes a long time. Sometimes as long as 10 minutes.

So what do I do? Resort to web-based email access which our corporate server provides. This seems to work because Firefox seems to consume less memory, and is "more responsive" compared to Thunderbird. Also, the issue could be with thunderbird having to initialize a large email store (I have anywhere between 3000 to 4000 emails in inbox at any time). The headers are synchronized first, and are available instantly. But the loading the body takes a lot of time.

So here is the idea: Enhance thinderbird extension so that it helps open email using browser - assuming that your webmail can take the URL with appropriate ID, and allows you to login without losing that ID...

Small niceties always help.


Wednesday, December 07, 2005
Future of template languages?

It seems like the templating mechanisms will continue to evolve. I came with some requirements and will watch how they will play out in future.

We need Javascript as well as Server side templates. Trimpath folks have a templating mechanism for javascript. Their javascript-equivalent of Ruby-on-rails has a good comparison of ruby template with their own templates (RubyRails Vs JavaScriptJunction ). One of good things this engine is the fact that it can be used both on server side (using Rhino) and client side. But my point is different: The same template should be rendered both on server side as well as client side. And that means some things are resolved by server, and some are rendered at client side. So how do we decide how to partition? For e.g. Layout is server side, but the contents in each boxes are necessarily driven by ajax. This in turn require JSON-RPC integration with underlying template mechanism. The objects used within the template need to be added to JSON-RPC bridge automatically. I should be able to simply add "" as one of the attribute to where the template is hosted, so the client-side template has access to server-side objects using JSON-RPC bridge seamlessly.

As the app devel cycle takes lesser and lesser time, the UI improvements will keep going on continuously. A simple "merge" operation should be sufficient to ensure that the developer-made changes are automatically integrated into next version of UI. This means templates should be designer-friendly and amenable to versioning, diff's and merges. This means that all the "code" part to be within attributes and special tags. Kid template language of Python does this right.

And again, assuming we spend time with UI, we require templates to be managed by content management system - and that means Wiki. And more important, we would like the capability to be uniformly available to end users as well. And this means we need to have "Safe" templates - those which can be edited from web itself. For example, Liquid, a ruby-based templating system, seems to do it.

Widget integration is going to be another interesting area. Dojo, prototype etc. already give us good widget environments. Widgets will probably make it easy to standardize on Layouts - such as 3-column, or 3-pane (like in outlook). How exactly should widgets get integrated with templating languages? In some sense, widgets seem to compete with standard templating approaches: A widget specificaiton is going to be very simple. Remember Dojo's ridiculously simple slideshow widget example specification? And the problem is, the widget is going to take inputs as parameters. Some of them will, well, be widgets. And this means that your template will basically be XML tree, and that's bad. (After all, templates should look like real HTML!) In any case, as long as browser can show this properly without requiring other servers, I think people will come to accept this approach. We would have to see how this will roll out. And not to forget, we are also talking of ajax-enabled widgets which need to integrate well with JSON-RPC or some such scheme.

In any case, javascript is going to be an important ingredient.


About this blog
All realms of collaboration:
  • Wiki. Weblogs
  • New Integration Platforms for combined structured and unstructured information: Wiki, Portals, Email Clients,
  • Collaborative Document editing, Collaborative knowledge building
  • Email Interfaces to collaborative shares
  • Information organization, management, Publishing: In context of organizations, individuals, Opensource projects etc.
About me:
Name:Vinod Kulkarni

Subscribe to Bloglines


January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
September 2003
November 2003
December 2003
January 2004
February 2004
March 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
May 2005
June 2005
November 2005
December 2005
May 2006
June 2006
October 2006

Powered by Blogger