Subject: Re: [pgsql-advocacy] PostgreSQL.org Design Proposal

From: "Dave Page" <[email-masked]>
Date: Fri, 29 Oct 2004 08:52:51 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mitch Pirtle
> Sent: 28 October 2004 18:26
> To: PostgreSQL www; PostgreSQL advocacy
> Subject: Re: [pgsql-advocacy] [pgsql-www] PostgreSQL.org 
> Design Proposal
> 
> Dave,
> 
> II am clearly offering to help (and not just complain), and 
> wanting to understand if my efforts would actually be used if 
> I did.  I'm also busy working on other FOSS projects, with 
> significant time involved. 
> So if I spend the additional time away from my wife and kids 
> then I want to know it was worth it - that's not too much to 
> ask, is it?

It will be, but you'll need to fit in with what we are doing, not the
other way aound. If you really feel you need to be doing something else
thoough, there are other projects that can be looked at - for example, a
new techdocs site; however, it would need a thorough investigation and
justification of any subequently proposed solution. Mirroring is not an
issue for techdocs, however, il8n should probably be considered.

> My objection to a do-it-yourself approach is that anything 
> beyond PEAR and PHP is proprietary.  That means that you 
> wrote it; and as such then you have to support it, and you 
> have to document it, and you have to improve it, and you have 
> to upgrade it to keep compatibility with changes to 
> HTML_QuickForm and DB and so on...  With a CMS, you'd 
> typically be using a finished system that had been developed 
> by dozens of people, with years of experience, with a 
> lifespan that supports itself (free upgrades).  Such a waste, IMHO.
> 
> I agree that mirroring is a huge problem, and anything less 
> than the heavyweight systems (Zope/Plone, for example) will 
> have major issues. 
> Mirroring a dynamic site in general is a major issue, and 
> switching to a homegrown one just adds to the complexity and 
> effort, no?

Which is why we investigated CMSs in depths before we started, and found
that even advanced ones such as Bricolage couldn't meet our requirements
:-(.

> And I wasn't being rude IMHO, I've already picked on Dave for 
> his browsing preferences.  He says he has a huge monitor, but 
> surfs the web like he is on a Mac Plus.  Having a design that 
> supports 800x600 to support the handicapped and comply with 
> accessibility laws is great in my book.  I just think Dave is 
> being a weirdo for using such a little browser window ;-) 
> Sorry that wasn't so apparent in my previous email.

Maybe (there are certainly people that know me better and probably
wouldn't disagree!), but there are two reasons for that:

1) I have users at work with visual problems who run large monitors at
low resolutions. In the UK it is a legal requirement for any
organisation to provide websites and other services in an accessible
form for such people.

2) Often when I'm browsing, I have many other windows open because I'm
programming. I don't want to switch between them all the time, I want
them side by side so I can read reference material, and code. Apps like
Visual Studion take a lot of real-estate, and I'd rather not compromise
that by being forced to use 3/4s of my screen just to refer to the libpq
docs.

Regards, Dave

---

From: Markus Bertheau <[email-masked]>
Date: Fri, 29 Oct 2004 18:34:29 +0200

> that even advanced ones such as Bricolage couldn't meet our requirements

In view of the fact that the current site does (probably) not only not
meet your requirements, but also doesn't meet the perceived needs of the
web site's users, wouldn't it be wise to adjust your requirements so
that bricolage or plone or whatever fit, in order to get something
going?

Thanks

-- 
Markus Bertheau <[email-masked]>

---

From: Andreas Pflug <[email-masked]>
Date: Fri, 29 Oct 2004 16:50:46 +0000

Markus Bertheau wrote:
  wouldn't it be wise to adjust your requirements so
> that bricolage or plone or whatever fit, 

This is probably the ultimately helpful hint for the novices working on 
the new site, we all know that the postgres community consists mainly of 
raw beginners...

Regards,
Andreas

---

From: Josh Berkus <[email-masked]>
Date: Fri, 29 Oct 2004 10:03:40 -0700

Dave,

> that even advanced ones such as Bricolage couldn't meet our requirements

No offense, but nobody "investigated existing CMSes in depth", or if they did, 
it was not discussed on WWW.    What happend in my recollection was that the 
people who were in favor of CMSes (like me) were not willing/able to do the 
work to set them up, and the people who liked a more nuts-and-bolts system 
were willing to do the work, so that's what we went with.  The people who do 
the work get to make the decisions on how it's to be done.

Bricolage, for example, runs the WHO web site, the Register, Radio Free Asia, 
and and several other major, multi-lingual sites.  It is also designed for 
mirroring, working on the idea of "burning" stuff to HTML files instead of 
dynamically served content.     It's quite capable of doing PostgreSQL.org.   
The problem is that it requires Perl Mason expertise to set up and design 
pages, and our WWW team is primarily HTML and PHP coders.

Gavin Roy is currently working on a system, Framewerk, which may become a 
better fit for our community once he gets export-to-static-html working.   
Actually, we could probably use it for Techdocs right now.  

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

---

From: "Joshua D. Drake" <[email-masked]>
Date: Fri, 29 Oct 2004 10:26:02 -0700

>Actually, we could probably use it for Techdocs right now.  
We are also considering it for the plPerlNG and plPHP sites.
We are waiting for it to stabilize (in terms of schema changes etc..)
a bit first.

BTW I don't know if anyone noticed but FrameWerk was a prizewinner with
the PHP 5 coding contest.. so go Gavin.

Sincerely,

Joshua D. Drake

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [email-masked] - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

---

From: "Gavin M. Roy" <[email-masked]>
Date: Fri, 29 Oct 2004 12:18:53 -0700

Joshua D. Drake wrote:

>
>> Gavin Roy is currently working on a system, Framewerk, which may 
>> become a better fit for our community once he gets 
>> export-to-static-html working.   Actually, we could probably use it 
>> for Techdocs right now.   
>>

Thanks :D  I wish it was then where it is now, I probably would have 
placed higher :x  We should be nearing a 1.0 release mid-November, 
though what's there now is usable, just sans installer, and is missing a 
few needed features for non-tech savvy users.

Gavin

---

From: Alexey Borzov <[email-masked]>
Date: Fri, 29 Oct 2004 23:56:44 +0400

Hi,

> pages, and our WWW team is primarily HTML and PHP coders.

Yes, exactly, so now we must choose between an ugly (I openly admit this) system 
  written in ugly PHP that *runs* the current development version of 
postgresql.org [1] (that BTW has some open TODO items [2]) and a wonderful 
state-of-the-art CMS written in magnificient Perl that could *potentially* run a 
splendid new postgresql.org, if only someone actually wanted to do some work 
instead of praising the virtues of that particular CMS.

Isn't the choice obvious? ;)

> Actually, we could probably use it for Techdocs right now.  

[1] http://wwwdevel.postgresql.org/
[2] http://wwwdevel.postgresql.org/todo

---

From: "Greg Sabino Mullane" <[email-masked]>
Date: Mon, 1 Nov 2004 00:40:27 -0000

> Bricolage...
> The problem is that it requires Perl Mason expertise to
> set up and design pages, and our WWW team is primarily
> HTML and PHP coders.
 
Well, in all fairness, I'm a Perl wizard who would actually
contribute a lot more to the web code were it not written in
PHP. :) There may be others.
 
Also, the author of Bricolage is fairly active on some of
our lists, and I'm sure would be very willing to help out.
Bricolage would actually be a really good choice for our
website (if not now, then later) as it is one of the best
products out there (in any category) that showcases PostgreSQL.
 
- --
Greg Sabino Mullane [email-masked]
PGP Key: 0x14964AC8 200410311939

---

From: Robert Treat <[email-masked]>
Date: Mon, 1 Nov 2004 15:44:32 -0500

> products out there (in any category) that showcases PostgreSQL.

I know no one believes that the web team ever looked at any CMS packages, but 
just a couple of the problems that bric had were supporting the interactive 
docs, duplicating content out of CVS, and the ability to do translations of 
content.  On the latter David even said that it was something that could not 
be supported *at the time*, and we certainly were in no position to hire him 
to do the work needed to get it supported.  AFAIK he did have plans to fix 
the latter for another client, but I'm not sure if it is done, nor feeling 
overly optimistic that there is enough developer support to help setup or 
debug a new installation for the postgresql website (since I'm sure it would 
require more than just David being willing to "help out")

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---

From: Alexey Borzov <[email-masked]>
Date: Tue, 02 Nov 2004 13:07:03 +0300

Hi,

> the PHP 5 coding contest.. so go Gavin.

Yes, it has achieved a whopping 18th place (out of 50).

I've downloaded Framewerk and gave it a quick review. There are some Bad 
Code Smells that will make it hard to manage in the long run:

1) HTML generated as PHP strings;
   It is not necessary to use some "template engine" but code generating 
data structures for output should be separate from code outputting this 
data which can be e.g. HTML file with minimal PHP. Changing the design 
done in the following way is *extremely* difficult:

       $ret .= "\n<form name='edit' action='$this->action' 
method='$this->method'>\n";
       $ret .= "<blockquote><table class='form' width='98%' border='0'>\n";
       foreach($this->fields as $field)
       {
         $ret .= "  <tr valign='top'>\n";
         $ret .= "    <td class=\"formitem\"";

2) Usage of homegrown i18n solution rather than some established ones
   Isn't it obvious from the first glance what this string does?
   {!i18n:visitors:{@visitors}}

3) Abstraction of DB API rather than usage of proper data access layer
   This is BTW the reason for poor PostgreSQL support in most PHP 
applications: their authors use such "abstraction layers", but design 
schema for MySQL and then just do minimal "translation" of queries they 
do. Upper levels should know nothing about SQL and just call lower level 
to fetch some data.

4) Lack of consistent coding standards.
   One can say many bad things about PEAR, but its code is at least 
readable and one always knows where to find things.

---

From: Robert Bernier <[email-masked]>
Date: Tue, 2 Nov 2004 05:41:38 -0500

Guys,

Where should the following notice be posted?

The office is making the move to creating a list of PostgreSQL people to hire 
as contractors who have Informix experience. Actually, my guess is that 
anybody who has a few years experience should look into making an application 
and getting their name on the list.

Here's the actual email that they sent me that will be posted:

----
SRA-America is having an open call for resumes/CVs for upcoming 
projects for 2004 and 2005.

If you have experience in the migration of the large 
commercial databases to PostgreSQL, or if you have worked extensively 
with PostgreSQL and another database we want to hear from you.

Please email your resume/CV to [email-masked]
----

thanks

---

From: "Joshua D. Drake" <[email-masked]>
Date: Tue, 02 Nov 2004 03:16:17 -0800

> Yes, it has achieved a whopping 18th place (out of 50).

I am sorry, did you have an entry in the contest that placed?

>
> I've downloaded Framewerk and gave it a quick review. There are some 
> Bad Code Smells that will make it hard to manage in the long run:
>
>   It is not necessary to use some "template engine" but code 
> generating data structures for output should be separate from code 
> outputting this data which can be e.g. HTML file with minimal PHP. 
> Changing the design done in the following way is *extremely* difficult:
>

Yea I would have to agree with this one, but I am sure that Gavin 
appreciates the feedback.

>   {!i18n:visitors:{@visitors}}

Well there may actually be a good reason for this.

> schema for MySQL and then just do minimal "translation" of queries 
> they do. Upper levels should know nothing about SQL and just call 
> lower level to fetch some data.

Well I am sure Gavin isn't suffering from the translation of queries 
issue but there is a lot of good reasons to abstract the DB API.

> readable and one always knows where to find things.

The product isn't even 1.0 yet and very few people are using it. If you 
are unhappy with it, why not donate some resources
and help make it a better product?

Sincerely,

Joshua D. Drake

>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if 
> your
>      joining column's datatypes do not match

---

From: Robert Treat <[email-masked]>
Date: 02 Nov 2004 10:25:05 -0500

> Please email your resume/CV to [email-masked]

Job posting should be sent to [email-masked]. 

Robert Treat

---

From: "Gavin M. Roy" <[email-masked]>
Date: Tue, 02 Nov 2004 08:28:55 -0800

>> Yes, it has achieved a whopping 18th place (out of 50).
Actually there were about 200 entries.  I suggest you look at the whole 
list and not the top 50 list :p

>>         $ret .= "    <td class=\"formitem\"";
This is the form object which is for backend admin form generation.  It 
generally has one purpose which is to make two column forms via 
objects.  While I'm not the author of this set of objects, I'd be happy 
to implement suggestions.  If you had to look that hard to find 
something like this, I'm pretty happy, since no one has given the 
project a critical review.

> appreciates the feedback.

Absolutely.

>>   {!i18n:visitors:{@visitors}}
I looked at some of the more popular i18n implementations, and decided 
that I could more easily implement an xml or pgsql table based 
implementation.  It's super flexible, and allows for pretty elaborate 
conditionals.  Perhaps you didn't look at the way the XML structure is 
set for the i18n tags?  Here's the one for the one you pointed out:

39	  <key>Visitors</key>
40	   <value>
41	    <language>English</language>
42	    <condition>$1 == 1</condition>
43	    <translation>There is currently 1 site visitor.</translation>
44	   </value>
45	   <value>
46	    <language>English</language>
47	    <condition>$1 != 1</condition>
48	    <translation>There are currently {@visitors} visitors.</translation>
49	   </value>
50	  </variable>

The great thing about the system is the fact it's very modular.  If this i18n system is sub-par, it would be very easy to implement the gnu system, for someone that wanted to deal with their files and create an interface for them.  I originally did look at gettext but came to the conclusion it wasn't designed for a living set of translations but rather for a programmer and design team to do all the translations up front, which is ultimately why I did things the way I did them.

>> lower level to fetch some data.
I designed the abstraction layer with PgSQL in mind, and with the idea 
that someone might want to come in and add support for something else.  
The way the abstraction layer works doesn't affect performance at all, 
and allows for some unique methods of querying data in blocks.  It's 
very easy to code for, and allows for completely different query 
structures for different backends, while not having to jumble data 
around.  There was a lot of thought of that went into how the 
abstraction layer would work, and while it is quite different than the 
way PHP normally handles queries, there is a reason for the two step 
approach, that I feel justified in creating.

> The product isn't even 1.0 yet and very few people are using it. If 
> you are unhappy with it, why not donate some resources

I've been making a concious effort to go back through and update 6 month 
old code to reflect how we're doing things now, and to enforce some 
standards on contributed code.  If you'd like to help clean things up or 
make some constructive criticism, I'd love to hear it.

Gavin

---

From: Alexey Borzov <[email-masked]>
Date: Wed, 03 Nov 2004 14:06:38 +0300

Hi,

> I am sorry, did you have an entry in the contest that placed?

No, but I maintain several well-downloaded OS PHP projects.

> and help make it a better product?

Why are you behaving so protectively?

I am already contributing to the project, by reviewing it and giving pointers to 
possible future fixes and enhancements.

Besides, if you want a project to ever reach 1.0 and have a lot of users, you 
have to consider architectural decisions in advance.

---

From: Alexey Borzov <[email-masked]>
Date: Wed, 03 Nov 2004 14:25:28 +0300

Hi,

Gavin M. Roy wrote:
> to implement suggestions.  

You mean people using your framework will be unable to use this form-generation 
class in the frontend of the website? Will they need to code all forms by hand? 
'Cause if you expect them to use it in frontend, they'll definitely want to 
change the design.

The suggestion is simple: abstract form generation from actual output. Generate 
an array of form elements' HTML and later iterate over it or even use something 
like Visitor pattern as QuickForm [1] does.

> If you had to look that hard to find 

Consider this: maybe I just know where to look and what to look for? ;)

> set for the i18n tags?  Here's the one for the one you pointed out:

It is impossible to say what string will be output by just looking at this 
placeholder in the template, while it is obvious when using gettext(). As for 
conditionals, gettext allows them, IIRC.

> approach, that I feel justified in creating.

You didn't understand my point. I mean the following: your upper layer still 
contains SQL queries, here is a typical example from TCMSViewer class:

       $this->Database->AddQuery("key_lookup", "SELECT a.*, b.*, 
to_char(a.created, '" . $this->parent->Configuration->datetime_format . "') AS 
update FROM cms_entries AS a, cms_keys AS b WHERE b.cmskey = a.cmskey AND 
a.cmskey = '$1' AND a.approved = 't' AND a.active = 't' AND a.language = 
'$language';");

As you see, the call only abstracts DB API, it does not abstract actual query 
which contains PostgreSQL-specific to_char() formating function.

If you did the Right Thing, there would be no query here but just a call to a 
hypothetical loadCmsKey() method of hypothetical DAO.

> make some constructive criticism, I'd love to hear it.

Create your own coding standards or adopt existing ones. Make all existing code 
follow them --- there are automatic code beautifying tools available, you know. 
Do not accept contributions not following the standards.

[1] http://pear.php.net/package/HTML_QuickForm

---

From: "Joshua D. Drake" <[email-masked]>
Date: Wed, 03 Nov 2004 09:43:39 -0800

> Why are you behaving so protectively?

I felt, possibly incorrectly that you were attacking what I consider a 
decent project. This could very well be what Josh Berkus was speaking 
about in terms of language barriers etc...

If that is the case I apologize.

Sincerely,

Joshua D. Drake

> 
> I am already contributing to the project, by reviewing it and giving 
> pointers to possible future fixes and enhancements.
> 
> Besides, if you want a project to ever reach 1.0 and have a lot of 
> users, you have to consider architectural decisions in advance.
> 
> TIP 4: Don't 'kill -9' the postmaster

-- 
Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [email-masked] - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL