gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@apache.org>
Subject Gump3 Presentation -- choice of technology
Date Thu, 30 Jun 2005 23:24:10 GMT
Thomas et al,

We need to pick a technology to use to display the contents of a database
via a webapp. We are in the "fortunate" position of having more technologies
available to use than we could wave a stick at. Clearly we could do the job
with all of them. Let's explore them and come to a mechanism for you to
decide which you want to use.

I won't determine how you evaluate the 'best' choice, that will be your
choice. At the end of the day much of OSS comes down to "scratch what
itches" which is often translated to "you do what you want, how you want,
when you want 'cos nobody is paying you/tellign you what to do". I know this
Google SoC case is slightly different, but the effective is there.

Some *personal* thoughts  that might factor into things are (1) which would
you find the most fun (2) which would you learn the most doing (3) which
would you benefit the most from learnng  (4) which would you think you'd
like to use again after this project. Added to that (1) which is the best
fit to the requirements (2) which is the best fit to the community
(Gump/ASF) (3) which is most likely to be maintained when you stop working
on it [there is life after any committer]  (4) what is the best fit for
users (least resistence to install/use.)

Again, we aren't trying to to be too "academic" -- we do want deliverable
results -- but much at ASF (and especially Gump) is about the long haul,
with the focus being on the community to support the code, not the code
alone.

To my knowledge here are the best known candiates (plus some others I've
heard discussed.)

 - Java JSP/Struts.
 - Cocoon (Stefano has spent significant time on this, he feels it is worth
evaluating.)
 - mod_python (Leo has spent some time on this, he feels it is worth
evaluating.)
 - PHP (why not?)

Clearly each of these (and there are plenty others) have
strengths/weaknesses, and I don't profess to know them all. To help you make
some determinations, here are some known requirements/thoughts for your
project.

- Gump3 presentation is simply about getting the data from the database onto
the screen. That said, there are lofty goals for it (and Stefano has great
insights here) that might lead to "charting" and/or "graphics/graphs".
Visualizing data isn't about dumping tables to the screen, but allowing a
humans to easily navigate an interpret. (Do yourself a favour and search the
archives for things marked [RT] in the subject). So, I suspect the
technology will want good visualization support.

- I could see the Gump3 webapp becoming a "first point of contact" w/ users,
so I could see it becoming much more than presenation. For example it might
need to go get output files for folks (for folks who don't have disk space
to store these in the DB.) Heck, it might become a front end for folks to
schedule runs/builds and/or kick of metadata parse checks. So, I suspect the
technology needs to be easily integrated.

- I could see this output of the webapp being data to reference (real-time
and historically) with URLs having a permanance to them. I could see us
generating RSS/Atom feeds from the webapp. I could see projects referencing
their "Gump Info" on their home page, and/or behind a logo. As such, I think
the technology needs full control over it's URL space.

That all said, I know this is needs to be focused project, with fixed time
allocated to it. As such, these last two thoughts are probably overkill.
Getting the data presented to the users is the only (first) goal.

Folks, please feel free to chip in your comments/reservations and
perspectives on all of these to help Thomas decide.

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message