[Linux-aus] Linux Australia Website

[Stewart Smith]

On Sat, 2006-11-18 at 12:52 +1100, Andrew Donnellan wrote:
> On 11/18/06, Michael Davies <michael at msdavies.net> wrote:
> > Integration is more about what the user experiences than what
> > language/tool the backend is written in/uses.  Think like an end-user,
> > not a programmer.
> 
> Yes, however integration also includes the admin side of things and so on.

(most of) the admin for MemberDB is web based, others still requires SQL
statements (patches welcome). There's a set of rules about what
everything in the DB means and UI should reflect this. There is
currently no way to do this without writing code (or if there is a free
way, it's hiding pretty well).

> Also the end-user integration is easier when the backend is integrated.

No. Please look at how MemberDB does integration with a site look.

Isn't it currently acceptable with the current LA site? It's not hard
coded to it.

> > No matter how "simple" there will be teething problems, and if you do
> > this with a membership database responsible for elections on a public
> > web server, you want to minimise them (remember the privacy laws in
> > this country?)
> 
> That's why you test it somewhere other than your main server first...

sure, although generating a similar data set to do full testing is
tricky.

I would love a bigger test suite for MemberDB - if you know of good
automated web application test suites, please let me know (or even
better, contribute the tests).

> The last time I used MemberDB was for the elections which was ages
> ago. My guess is that most people (other than ctte members) probably
> use it about once a year or less. There is a fair amount of time to
> test it.

You're forgetting the human time. 

> > Member_db spat out the SQL password at one point due to a bug (sorry
> > Stewart for bringing that up :-)  Anything we can do to make this
> > migration simpler should be adopted.
> 
> That *is* a nasty bug; of course that shouldn't cause much of a
> problem for LA if the database is configured only to allow from
> localhost :)

that, of course, was the case - so only people with shell access to the
box could have used that password.

> > Keeping it a separate application,
> 
> Less maintainable, more difficult to integrate.
> 
> > embedding it's output inside what
> > Joomla/Drupal/Plone/Typo3 produces,
> 
> Sometimes that can take more code than rewriting the app...

but not shorter than testing it.

> > or writing it from scratch - let's
> 
> If we use a non-PHP based system this would definitely be my choice.
> If a PHP based system is used it can be integrated as some sort of
> module.

You don't need to do that - you just need to make it *look* similar.

there would be no cross-functionality needed - except authentication.
and auth can go directly to the DB and run a SELECT query easily.

if anything, we could write a $(favourite fashionable language of the
day) authentication module.

> > just get away from the NIH[0] attitude and the "XYZ language/tool
> > sucks, trust me" mentality and do a proper analysis of the options so
> > that we can choose the right tool, technology, and approach that makes
> > sense, and not jump in feet first to solve the wrong problem.
> 
> Well yeah, there's no point discussing this until we have any idea
> what we will use and why we will use it. We still haven't got an idea
> whether we should use Drupal, Joomla, Plone and Zope, a custom written
> one, or whatever.

i vote anything but a custom one. The world does not need yet another
LAMP based CMS.

> As I've been looking around Plone is looking more and more attractive
> from an admin POV. It appears capable of practically anything except
> perhaps the store and memberdb.

suggestions on what to use for the store? no reason we have to have
everything in 1 software package - modularity is good.

-- 
Stewart Smith (stewart at linux.org.au)
Committee Member, Linux Australia

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.linux.org.au/pipermail/linux-aus/attachments/20061120/179c4687/attachment-0001.pgp