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.
-Vinod
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 "remotehost=xyz.com" 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.
-Vinod
