Jonathan Bond-Caron - Ideas & Experiments

Distributed Cache - Velocity

I always enjoy reading Microsoft tech announcements simply because they just seem to "nail" business requirements and building the proper solutions / technology.

The quote the announcement: "Distributed cache is becoming the key application platform component for providing scalability and high availability. In-memory caching has been traditionally used primarily for meeting the high performance requirements of applications. By fusing caches on multiple nodes into a single unified cache however, the distributed caches offer not only high performance, but also scale."

Microsoft released a first CTP (technology preview) of their distributed caching technology called Velocity:

From the readme: "Velocity" distributed cache is provided in the form of a cache cluster, simplifying your application code by managing the complexities of load balancing behind the scenes. When you use "Velocity," you can retrieve data by using keys or other identifiers, called tags. "Velocity" supports optimistic and pessimistic concurrency models and a variety of cache configurations.

For those familiar with memcache (open-source), it's the same type of solution. Velocity however seems to be a much more enterprise ready package with advanced caching features.

It's further interesting that Velocity uses ports: 22233 (data) and 22234 (monitor cluster nodes), looks like we're going to need a distributed caching 'RFC' and protocol some time soon.

The full announcement is here:
http://blogs.msdn.com/velocity/archive/2008/06/02/introducing-project-codename-velocity.aspx

Short PHP array synthax

There's an RFC that has been recently declined through the PHP internals list. It is a minor change/patch to introduces a short synthax to declare arrays in PHP.

To declare an array in PHP, you currently use the following synthax:



$a = array('foo' => 'bar', 'nestarray' => array(0, 1, 5));

The proposed patch (a few lines) would allow to declare arrays in a shorter form:



$a = array('foo' => 'bar', 'nestarray' => array(0, 1, 5));



// New synthax

$a = ['foo'=> 'bar', 'nestarray'=> [0, 1, 5]];

// Or

$a = ['foo': 'bar', 'nestarray': [0, 1, 5]];

This notation is used by many programming languages, most notably javascript. Since PHP is essentially a programming language used for the Web, my opinion is it makes perfect sense to support a javascript-like notation for arrays.

There's some resistance from the core developers and overall there were too many veto (negative) votes. I definitely understand their concern but feel it's a natural evolution of the language, this to me seems like something most users would want to see in PHP.

Hopefully, the PHP community can speak out enough to get better idea of what the users / php community wants.

The actual proposal and more info at:
http://wiki.php.net/rfc/shortsyntaxforarrays.

Advantages of BSD

This one made me smile so I had to share it, there's a 25 year old bug that has just been fixed with seekdir() on all BSD systems. For details, see

http://www.osnews.com/story/19731

And the actual patch for FreeBSD is now available:

http://www.nabble.com/i386-121656:--libc---PATCH--telldir-issues-td16019215.html

There's something wonderful about the open-source community and how problems get fixed... well eventually Generally, BSD licensed projects freebsd (os), postgresql (database), dojo (javascript) have strong communities and in my opinion are great projects to be involved in.

BSD is a great license to study, modify and learn from software but also to collaborate with people from many different backgrounds, academic (research & students), corporate, hackers and so on... Happy BSDing

Bad Trade Day!

The HABS today have failed to grab Hosa from the Atlanta Trashers. It's a major disappointment for myself and all fans who were hoping to see the sharp shooter at Montreal!

It's not so shocking that we failed to get Hosa but that the HABS have given away Huet to the Washington Capitals for a mere second round draft pick. The valuation of our ex-#1 keeper seems both humiliating for HUET and the HABS.

After listening to Bob Gainey's press release, I'm still stunned by the news. Though I'm happy to see Carey Price as the future of the habs in net, my immediate reaction is we gave away Huet for very little in return.

Running dojo or javascript tookit on the SERVER side?

If you are not familiar with .NET and the precious runat="server" or runat="client", have a look a at: http://www.aptana.com/jaxer

The idea is simple and very very practical. In some situations, you may want to run code on the server OR on the client. The problem with a lot of javascript frameworks is they do a LOT of work on the client side. What if we could make the server work a little harder?

Based on John Resig's work,

http://ejohn.org/blog/bringing-the-browser-to-the-server/

I convinced myself I could create a "template parser" for dijit widgets that would read the following tags:



<dijit:form:CheckBox id="cb" runat="server"/>



<dijit:form:CheckBox id="cb2" runat="client"/>

The first part was making sure that a dijit widget could be created on the server side.
Amazingly after some tweaks, this works:



C:\Utils>java -jar js.jar

Rhino 1.6 release 7 2007 08 19

js> load('env.js');

js> window.location = 'test.html';

test.html

js> var djConfig = {baseUrl: "Z:/GDECORE/js/OpenAjax/dojo/"};

js> load('Z:/GDECORE/js/OpenAjax/dojo/dojo.js');

js> dojo.require('dojo._base.html');

[object Object]

js> dojo.require('dijit.form.CheckBox');

[object Object]

js> var widget = new dijit.form.CheckBox({id: "cb", name: "cb"}, dojo.byId("test"));

js> print(dojo.body().innerHTML);

<div role='presentation' waiRole='presentation' class='dijitReset dijitInline dijitCheckBox' widgetId='cb'><input dojoAttachEvent='onmouseover:_onMous

e,onmouseout:_onMouse,onclick:_onClick' id='cb' class='dijitReset dijitCheckBoxInput' value='on' tabindex='0' type='checkbox' dojoAttachPoint='focusNo

de' name='cb'/></div>

The template parser has now been written and several more tests are needed before a first release!

Sun-mySQL or Sun-PostgreSQL?

It's old news by now but I was recently reading "Sun buys mySQL" articles such as this one:

http://devzone.zend.com/article/2979-Did-you-hear-Sun-was-buying-MySQL

I think like lots of PostgreSQL fans, I was first shocked by Sun's move. Sun has been sponsoring PostgreSQL for quite some time now which in my opinion currently stands the best open-source database for the enterprise. So why did they buy mySQL?

Popularity & Marketing
mySQL seems to be the poster boy for web 2.0 and building a database driven website. Historically, the mySQL DB driver has been bundled with PHP natively, so it quickly became the 'M' in the LAMP stack and the open-source database. It has a catchy name and does most of what you would expect from a database. For me, there's no doubt that it makes sense for Sun to buy mySQL and offer better support for the database.

The Itch
The hopes for every postgreSQL fan is that Sun will not favor mySQL over PostgreSQL. In fact, the hope is that Sun can help steer mySQL to a direction closer to postgreSQL, i.e. support more properly the SQL standard and everything a relational database should offer.

For postgreSQL to gain wider adoption, it definetly needs a name change! But then again, maybe the wonders of postgreSQL are best kept as a "secret"?

Debate over Proposed ECMAScript 4th Edition

There's a new exciting debate over the ES4 proposal which is available online at:
http://www.ecmascript.org/es4/spec/overview.pdf

The reason?

Besides some people arguing over the complexity and possibly over-engineering of the new language, there are major corporate implications. Microsoft may not want to implement ES4 and it's quite unclear what their plans are with IE8. Does it make sense for Mozilla, Opera and Safari to implement a new javascript engine if Microsoft (IE) doesn't follow? Probably not.

But some might say, implement the standard and let Microsoft (possibly) follow up later. The problem is that for developers (scenario: IE doesn't implement the standard), we are stuck in the same interoperability mess when building web applications. Hack and hack after hack to support either buggy or non-existing implementations! It's further unclear if Microsoft has any interest for javascript to succeed in the long run and become a driving force in the success of web applications. The corporate strategy of Microsoft is not transparent with regards to their web technology such as Silverlight (brings .NET to the browser). In short, business is getting in the way of collaboration and benefiting the end users. On the other end, it's unclear how Adobe and Mozilla are related and if the donation of actionscript to Mozilla puts Firefox at an advantage to implement this proposed standard compared other browsers (IE, opera etc...).

Open Standards

No doubt, the solution is for browser vendors to actively implement and support a javascript engine according to the same standards. It will be interesting to see how this unfolds, important communication and decisions are ahead with regards to new web standards.

On a personal note, I like some parts of the proposed standard though I believe there's some over engineering with the type hinting. I am a strong fan of interfaces and classes.

Integrating jquery, dojo, Ext-js, YUI, tibco GI, AjaxControlToolkit, Adobe Spry

I've pushed forwards some more the concept already layed out by dojo and I'm at a stage where I'd like to get feedback from organizations and developers. I believe this type of standard would help foster more innovation and constructive competition among AJAX toolkits. In my opinion, too much effort is being spent trying to duplicate other toolkits features.

You can view the latest work here:
http://www.openmv.com/OpenAjax/tests/all-compressed.html

I've opened a proposal on OpenAjax:
http://www.openajax.org/member/wiki/Interoperability/RegisterResource

Some of you might be wondering, that's a lot of code! That trying to load all these frameworks probably sounds like a really bad idea. But with projects like a "javascript linker" that can remove used functions, there's a whole lot more trimming that can happen. The same is true for CSS.

There's still no CSS loading but don't worry, that's the next step.

Integrating jquery, dojo and Ext-js

I am sure a lot of you have often wondered: why can't open-source javascript frameworks like dojo, YUI, jquery, prototype and the gazillion number of other alternatives work together? Why should I have to choose one framework over another when all I want is nice widget X from framework A and nice widget Y from framework B? How far apart are the frameworks and how complicated would it be to have some level of integration?

First off, lets remember that each framework is built according to certain interests and goals in mind. This is fine and each framework is expected to take their own approach to solving similar problems. What really frustrates me is the energy and time that goes in open-source javascript toolkits / frameworks (call them whatever you like) and the lack of interoperability, collaboration between these competing toolkits. There's any amazing amount of (free) time that is wasted developing "competing" widgets while that time could be spent developing open-source components that are re-usable for other toolkits.

Given the frustration, I finally decided to do something about it and looked at how most frameworks could be integrated.
The results of the first step can be seen here: http://www.openmv.com/tests/dojo-ext-jquery.html

First Step?

The first step to me was clear, given the source of a javascript file, I needed to be able to figure out what this file needs to run successfully (its dependencies). After some research on a couple of frameworks, it appeared that Dojo had done a fair amount of good work in this area.

In dojo, each javascript file has a:



dojo.provide('dijit.layout.ContentPane')

dojo.require("dijit._Widget");

dojo.require("dojo.parser");

Mainly each javascript file declares what it provides (dojo.provide) and what it needs (dojo.require) -- its dependencies.

This sounds like a great start! But can we force other frameworks to use a dojo.require? Would this mean that a piece of the dojo base would be required in other frameworks? This doesn't seem at all ideal, especially if all you want to use is jquery. What we need is some sort "I play nice with other frameworks" interface.

Proposed Solution?
The WTI (Web Toolkit Interface).

http://www.openmv.com/tests/resources/js/wti.js

In short, by simply adding the following 5 lines to dojo:



if(typeof window.wti == "undefined") {

  var wti = dojo;

  var wti.require = dojo.require;

  var wti.provide = dojo.provide;

}

The toolkit now says "Yes, I play nice other frameworks" (by implementing the WTI interface). So now that we have 1 framework thats taken care of, we also want jquery and Ext-JS to play nice.

We can do this by adding these 5 lines to jquery and Ext-JS:



if(typeof window.wti == "undefined") {

	var wti = {};

	wti.provide = function(resourceId) {};

	wti.require = function(resourceId, /*optional*/resourceType) {};

}

That's it?! This is going to work? Not quite, each javascript file must then declare what it provides and what it requires:

For example:



wti.provide('jquery.interface.ifxscale');



wti.require('jquery.base');

wti.require('jquery.interface.ifx');

wti.require('jquery.interface.iutil');

Given these modifications, we now know enough information about each javascript files to integrate the frameworks / toolkits together. To give a small demo, I tweaked a little the dojo builder (to look for wti.require), and managed to compress jquery, Ext-js and dijit into 1 single file.

You can view the end result here
http://www.openmv.com/tests/dojo-ext-jquery.html

Basically this works:



		dojo.require("dijit.layout.ContentPane");

		dojo.require("dijit.layout.TabContainer");

		

		// Load jquery animations

		dojo.require('jquery.interface.ifxscale');

		dojo.require('jquery.interface.ifxshake');



		// Use jquery as $ selector

		var $ = jQuery;

		

		// Load Ext resources

		dojo.require('Ext.ux.Accordion');

		dojo.require('Ext.widgets.DatePicker');

		dojo.require('Ext.widgets.layout.ContentPanels');

		dojo.require('Ext.widgets.layout.BorderLayout');

I will of course be making all work available online, and contributing patches to dojo, jquery, Ext-js. This is a simple proposal that I hope will motivate some level of interoperability between javascript frameworks in one form or another.

Comments are very much welcome.

Step 2?
The next step will consist of modifying javascript files so they declare other types of media / resources they depend on, for example:



wti.provide('dijit.layout.ContentPane')



wti.require("dijit._Widget");

wti.require("dojo.parser");

wti.require("dijit.themes.dijit", '.css');