Lóránd Somogyi

You’re building a web application with some nice interface. You use JQuery and a bunch of Javascript libraries on top of it. So you download those applications and place them into your deployable package and reference them from your application.

But why do we wrestle with resources of (OSS) libraries? Downloading new versions, copying the resources to our application and deploying it again and again for each and every application.

I think W3C get that right. For example with XML Schemas: Usually XML Schema files (XSD) should be placed on some accessible URL on the Internet (or Intranet). So when you define your XML with schema definition you provide an URL which points to a resource on the Internet. Each application using the XML can fetch the Schema file and use it. Those URLs are fix URLs, does not change over time. So why don’t we do the same with Javascript files, images, etc.?

For example those popular FAMFAMFAM icons could be accessible one-by-one. Or just think of most popular JavaScript libraries like JQuery, Prototype, YUI, script.aculo.us, – you name it, – all could be accessible on a well defined URL. In that case we could access them whit a simple URL. Set up would be easy as pie…

The next step: repository

We could provide a central repository for these resources. Something similar to Maven Repository but for other resources. It would be enough to have a unique name (as an Id).

For example I would put JQuery to a next path:

http://ossresources.org/jquery/jquery.js

Versions

Of course we need versions too. Or we could end up with non-working websites or applications from time-to-time.

My proposition would be, to extend the path from above to (kind of Maven way):

http://ossresources.org/jquery/1.3.2/jquery-1.3.2.js

Of course we could have Meta-versions too, like latest, snapshot, etc..

There are some problems with the setup from above. Lets see…

The first problem: Prussic Corporate Environment

In corporate environment sometimes there are no access to the Internet, or the there are prussic proxy rules. In that case there is no access to the resources from above. – There is a same problem with XML Schemas too.

The only solution to this, is to set up a corporate repository that would proxy the resources to the Intranet. – Similar to Maven Repositories, like Artifactory or Nexus.

The second problem: Licensing

Okay. I’m not a lawyer but I think this is actually the bigger problem. We should find a way to distribute licences with resources too. We might put licences beside the resources, or provide a link for each resource. I just don’t know, I hope there are some folks that know the answer, and we could create a real repository…

Conclusion

I think this was the intention of the inventors of the web, but as usually something went wrong…

Lots of software companies does not Open Source their software. It is a bad practice, and a waste of money. Open Souring your software has a real good ROI.

This article is first of all for business people leading software companies, or for those who pay for software development. Actually for all those who are decision makers. On the other side I hope it will be interesting for software architects, developers too.

This is not mean to be an in-depth analysis or an article about sheer numbers, charts and stuff. It’s just few thoughts and examples from the real world.

Read more…

This is the next article on planning, and what could go wrong on a huge project, and what to do to avoid pitfalls.

Read more…

Working on a huge legacy system as a software architect, the most valuable lesson learned is:

plan, plan, plan and do it as soon as you can

Beside of normal design planning, resource planning and stuff you might think of, there is different aspect of planning. Read more…