PlatformCandidates

From wiki.ucalgary.ca
Revision as of 20:32, 10 March 2006 by Dnorman (talk | contribs) (Reverted edit of Mhzibh, changed back to last version by Dnorman)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Here are the candidates for Pachyderm 2.0 platform:


PHP

This is a widely used open-source web development language.

Pros

  • The current version of Pachyderm is written in ASP, a similar scripting language. It would be a fairly simple task to port functionality as it stands from ASP to PHP, allowing for a phased upgrade/release of the application from 1.0 to 2.0.
  • The expertise of the team seems to lean in the direction of PHP, so there would be a strong motivation to use the teams strongest skills and use an implementation language they know well.
  • Some code has already been written in PHP, and could be used from 2.0 alpha directly into 2.0 beta / release.
  • Many of our needed functionalities (database connectivity, authentication, XML parsing, image handling, Flash processing) are already written and can be found in the php community via the PEAR site, or other PHP sites.
  • Many functionalities can be found in patterns written for PHP, and can be impolemented fairly easily into our application.
  • PHP has a lot of interchangeability built into it (runs on a variety of webservers and OS'es, and interoperates with many databases out of the box). So the options for platforms are extended greatly without a great deal of work.
  • PHP allows for model-view separation if implemented correctly
  • PHP 5.0 is now in RC2 and can be assessed for use on the project -- it's much more efficient and has a strong object model built into it.
  • PHP ties very easily into back-end java and C libraries, allowing for use of classes from other languages directly in the PHP code where necessary.
  • PHP is a world-class language and is used in very high-volume, high-availability sites (such as Yahoo). It is one of the possible 'P's in LAMP architecture, and is a world standard.
  • PHP is incredibly easy to install, and runs very efficiently with a variety of webservers.
  • PHP is very easy to use and understand and has a very shallow learning curve associated with it. Prototyping out functionality can be done very quickly.

Cons

  • PHP is a language, not a CMS or application, so you have to assemble the bits and pieces or build them by hand -- you don't have an install-out-of-the box (and modify) experience.
  • PHP is not as efficient as Perl as a web applications language. Much of this is addressed in recent releases of PHP.



WebGUI

This is a content management system with a Perl/MySQL back end. It is highly template oriented, so that the look and feel of an entire site, or any component can be customized in HTML.

Pros

  • User account management is provided.
  • Template architecture gives nice Model and View separation.

Cons

  • Accessing custom tables requires custom code.
  • Pachyderm adopters would have to install WebGUI first.
  • There may be a sufficiently different object model from what is necessary for Pachyderm to cause a great deal of custom code to be written -- so much so, that the original benefits of the framework are outweighed by the amount of tweaking necessary to get it to function.

JSP

Description:

Pros:

  • JSP is an industry standard, and is used on enterprise level sites. It's tried and tested and very efficient, when impemented correctly.
  • Many patterns exist for JSP, and can be implemented directly with a great deal of ease.
  • JSP sits on top of application servers, which often have things like user authentication built right in, ready to be implemented.
  • JSP has model-view separation built into its conception.
  • JSP allows for java to be run directly in each page if necessary -- access to underlying classes is very powerful.

Cons:

  • Requires a great deal of back-end class/bean construction to support the jsp pages -- there will be a lot of overhead work just to get the thing moving.
  • The JSP model is very different from the ASP model on the face, and requires a complete rethinking of the application architecture.
  • Requires an additional server (application server) on top of a webserver, and is an added level of complication to the system that may be unnecessary.

WebObjects

Description:

Pros:

  • It's Just Java, with some extra stuff thrown in a wrapper around a runtime environment.
  • Frameworks and libraries are used extensively, making code reuse trivial.
  • It Rocks
  • D'arcy and King know it.
  • Josh is learning it.
  • It would allow us to implement Pachyderm as a set of plugins for APOLLO, which would provide 80-95% of the required functionality "for free". That's a Good Thing.
    • We'd be able to focus our development on the specific bits of functionality that APOLLO lacks wrt. Pachyderm Requirements (namely the publish-to-flash stuff)
    • Asset management, User authentication, all kinds of other infrastructure-level stuff is available via APOLLO. We don't have to reinvent wheels again.
    • Able to leverage the workflow metaphor from APOLLO - task oriented steps to complete a job.
  • Pervasive Model-View-Controller paradigm, making it easy to separate data from logic from presentation.
  • Easy to do things in a modular way.
  • Able to tie in other java libraries as needed (flash generation? XSLT? Other stuff?)

Cons:

  • There is a lack of experience with this application, for at least one of the system engineers on the project (Joshua), and there would be a learning curve that could negatively impact the project schedule.
  • Adds requirement for deployment - must purchase a WebObjects license for each deployment server. Not a big deal at $99US. WebObjects Deployment officially supported on Win2K Pro/Server, Solaris, MacOSX. Deployment works on Linux as well (without official support from Apple).
  • A wee bit of a learning curve.

Notes:

  • Authoring is "best" on MacOSX, but is possible on other lesser platforms via the Eclipse IDE and WOLips plugin. Also, projects can be compiled via Apache Ant through the Project Wonder tools.
  • Will be necessary to build some pretty cool installers to get all the bits into the right places.



Zope

Description:

Pros:

Cons:

  • There is a lack of experience with this application, for at least one of the system engineers on the project (Joshua), and there would be a learning curve that could negatively impact the project schedule.

Perl

Description:

Pros:

  • Perl is a world-class web applications language, and is incredibly secure, efficient, and well-used. It is mature, well supported, and well tested.
  • CPAN is an incredible resource that can be searched for much of our needed functionality. It is possible we could build much of the application just by installing perl modules from CPAN.
  • Mod_perl allows for incredibly fast and efficient Perl code, which is functional at the enterprise level of use.
  • Certain Perl modules, such as DBI, allow for a great deal of abstraction and thus allow for a great deal of interoperability between implementation platforms.
  • Perl's built in templating allows for extremely easy model-view separation.

Cons:

  • Perl is not as easy to use for web applications as PHP, and usually requires a little more set-up work to get up and off the ground (especially if using mod_perl).
  • Perl's object model is cludgey and can be problematic if not followed with discipline on the part of the programmer.