-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 22 Jun 2008, Andrew Michael Lynn wrote: > [snip] > I am tempted to fork this thread into defending the role of > government funded laboratories in implementing technological and > engineering innovation, but that would dilute the direct answer to > the statement above - which is far more important. It is precisely to > avoid vendor or platform lock-in that we are sifting through the > proposed components to focus on open source - and pasting it on this > list to gauge the response of the community in using them. Most > members on this list would have the time, skills and resources to be > able to click-start the portal components, fewer provide tuning and > security, but probably none can provide the legal indemnity for > developing such a portal. Hence the need to rely on "enterprise" > builds and a framework that has indemnity built in. The nimbleness > would be on how easily one can get support and extensibility to it, > which - to me - is dependent on how easy it is for the community to > participate.
If you ask me (which you did, so don't complain now ;) an infrastructure for a project of this magnitude and visibility needs a few critical qualities. Let's have a look at each of these (feel free to add/subtract your own), before we start deciding what framework, applications, etc. will be deployed. At least if we know what we want we can evaluate our options more intelligently and hopefully come out with a better solution overall. 1. Reproducibility. This specific application (in which I include the infrastructure, frameworks and applications) would be one of the first of its kind in the world. Given that, and assuming this effort is successful, I'm sure we'll see tons of people wanting to deploy the same or similar applications for their own purposes, whether directly for drug discovery, for other bioinformatics related work or for a totally different end altogether. Unless it is easy to re-deploy the application, we might succeed in our immediate objective (OSDD) but would have failed in our larger, implicit goal of making a useful scientific portal and a model for others to adopt easily. Which immediately leads me to: 2. Portability. The application must run on as many and as diverse a set of platforms (hardware and OS) as possible. Having an app that only runs on, say, Linux is again counter-productive to our larger ends. An app that spans Linux, OpenSolaris, Winduhs, *BSD, AS400, handhelds (OK, maybe not, but you get the idea) as its target platforms makes a much more compelling story. 3. Flexibility. As little as possible must be hard-coded into the app. To take an example, I'd strongly recommend that all back-end services be made visible as and only consumed as web services, e.g. through SOAP. This ensures the following: - - You can change the complete structure of the back-end service without impacting the front-ends, which continue to function as before since the API hasn't changed. Oh, IBM is offering us their supercomputer for the back-end calculations? Cool, just make sure it follows the same SOAP API and the rest of our portal continues functioning without a hiccough. - - You can have different types of front-ends (web, GUI, handheld, sight challenged) consuming back-end services for different functions and different classes of users. Yes, this is more resource-hungry than a hard-coded, tightly-integrated app, but if you have ample hardware it's also much more flexible. That was an example, you can think of many more. 4. Standards compliance. Wherever standards exist in a domain we absolutely must develop and deploy applications that adhere to those standards. One of the biggest mistake that we as coders and sometimes as designers make is to try to second-guess our users; ``Oh, I don't think that anyone will ever want to use my Hello World program in the Space Shuttle''. One word (OK, three words): WE DON'T KNOW! So instead of trying to perform the Herculean, if not impossible task of analysing what scenarios the app will be used in, let's choose the simpler, albeit more painful way. We will adhere to standards, ensuring adapting the application to different environments is as simple as possible. 5. Architecture, Design and Coding Standards Compliance. Being an old fogey, the one architectural standard that I stick to is the MVC (Model/View/Controller) paradigm (http://en.wikipedia.org/wiki/Model-view-controller). At the very least, let's adhere to that. That means (sorry, PHP and JSP freaks) first of all no code/HTML khichdi -- if you want dynamic HTML, you use a templating system. I could go on but I'm sure the coders and designers here would be able to provide more standards that we must adhere to for the application. Your additions/modifications welcome. Do remember, though, we're not discussing specific technologies here, only the parameters for evaluating technologies. Regards, - -- Raju - -- Raj Mathur [EMAIL PROTECTED] http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F PsyTrance & Chill: http://schizoid.in/ || It is the mind that moves -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIXnB5yWjQ78xo0X8RAhA9AJ9r95VjeLcsq/WO6IUNQSi1xE4dYgCggVUe Ve7NYFHOD9Ctzd2VQEBPZak= =f7/F -----END PGP SIGNATURE----- _______________________________________________ ilugd mailinglist -- [email protected] http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/[email protected]/
