public inbox for [email protected]  
help / color / mirror / Atom feed
Re: Integration Requirements WAS: Launching PostgreSQL KB Project Mark 2
6+ messages / 4 participants
[nested] [flat]

* Re: Integration Requirements WAS: Launching PostgreSQL KB Project Mark 2
@ 2005-12-02 23:28  Josh Berkus <[email protected]>
  0 siblings, 0 replies; 6+ messages in thread

From: Josh Berkus @ 2005-12-02 23:28 UTC (permalink / raw)
  To: pgsql-www

Folks,

While we discuss on the *other list* the business requirements for a 
Postgres KB, it would be really helpful to get together on *this* list a 
document giving the requirements for projects to be incorporated into the 
PostgreSQL.org web infrastructure.  Such a document would be very helpful, 
as well, to others wanting to add things to the web site.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Integration Requirements WAS: Launching PostgreSQL KB Project Mark 2
@ 2005-12-03 08:21  Dave Page <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Dave Page @ 2005-12-03 08:21 UTC (permalink / raw)
  To: [email protected]; pgsql-www

Well, just to start throwing ideas around;

- Moving data; originally we'd looked at exporting from the cms into the filesystem, and having script that did a cvs add/remove/commit over the entire tree, into the main web CVS. This is still preferrable from an 'ease of rebuilding' point of view, but might be easier just to rsync the content from the filesystem of the cms machine to wwwmaster.

- Data format; pages should probably be in our standard template-style XML. 

- Navigation; Gevik was working on a tree-style thingy in PHP. Perhaps the CMS could export an XML file describing the navigation tree, which the PHP handler on the main website could use to generate it's treeview in dynamic mode. By accepting some sort of pointer to the currently selected node as a GET value, we should be able to make the tree fully mirrorable.

Thoughts?

/D


-----Original Message-----
From: [email protected] on behalf of Josh Berkus
Sent: Fri 12/2/2005 11:28 PM
To: [email protected]
Subject: Re: [pgsql-www] Integration Requirements WAS: Launching PostgreSQL KB Project Mark 2
 
Folks,

While we discuss on the *other list* the business requirements for a 
Postgres KB, it would be really helpful to get together on *this* list a 
document giving the requirements for projects to be incorporated into the 
PostgreSQL.org web infrastructure.  Such a document would be very helpful, 
as well, to others wanting to add things to the web site.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend




^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Integration Requirements WAS: Launching PostgreSQL KB Project Mark 2
@ 2005-12-03 17:35  Magnus Hagander <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Magnus Hagander @ 2005-12-03 17:35 UTC (permalink / raw)
  To: [email protected]; pgsql-www

> While we discuss on the *other list* the business 
> requirements for a Postgres KB, it would be really helpful to 
> get together on *this* list a document giving the 
> requirements for projects to be incorporated into the 
> PostgreSQL.org web infrastructure.  Such a document would be 
> very helpful, as well, to others wanting to add things to the 
> web site.

Josh, you are doing this backwards. You said it yourself in another
mail, start with the *functinoal requirements*.

At this point, the integration requirements should be "work directly in
the current website without any other product". If this cannot be done,
then we need to look at other products. But we cannot answer this
question until we have the functional specification.

My suggestion therefor - write a functional specification *completely
without considering what technical issues might show up with either
one*, and then we take it from there. And consider doing this on a more
"diplomatic" place than a technical mailinglist for a different project.


One quick comment on Daves mail:
> - Moving data; originally we'd looked at exporting from the 
> cms into the filesystem, and having script that did a cvs 
> add/remove/commit over the entire tree, into the main web 
> CVS. This is still preferrable from an 'ease of rebuilding' 
> point of view, but might be easier just to rsync the content 
> from the filesystem of the cms machine to wwwmaster.

I think long-term, just dumping the files over is not a managable idea
unless we have corporate committment for maintaining the backend.
Because sure, the website will work, but if the backend goes down nobody
will be able to use any of these uber-cool KB functions that's the whole
reason it exists. It's more like a stop-gap solution.

(Bottom line, of course, I still think this should be *actually
integrated* in the main website, and not just copied over from somewhere
else. If possible. Again, see above point, it's way to early to actually
comment on that now if the project is run that way.)


//Magnus



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Integration Requirements WAS: Launching PostgreSQL KB
@ 2005-12-04 01:24  Bruce Momjian <[email protected]>
  parent: Magnus Hagander <[email protected]>
  0 siblings, 0 replies; 6+ messages in thread

From: Bruce Momjian @ 2005-12-04 01:24 UTC (permalink / raw)
  To: Magnus Hagander <[email protected]>; +Cc: [email protected]; pgsql-www


The only comment I have is that I hope those who want a knowledge base
realize it is a huge job, and requires people with technical knowledge.

---------------------------------------------------------------------------

Magnus Hagander wrote:
> > While we discuss on the *other list* the business 
> > requirements for a Postgres KB, it would be really helpful to 
> > get together on *this* list a document giving the 
> > requirements for projects to be incorporated into the 
> > PostgreSQL.org web infrastructure.  Such a document would be 
> > very helpful, as well, to others wanting to add things to the 
> > web site.
> 
> Josh, you are doing this backwards. You said it yourself in another
> mail, start with the *functinoal requirements*.
> 
> At this point, the integration requirements should be "work directly in
> the current website without any other product". If this cannot be done,
> then we need to look at other products. But we cannot answer this
> question until we have the functional specification.
> 
> My suggestion therefor - write a functional specification *completely
> without considering what technical issues might show up with either
> one*, and then we take it from there. And consider doing this on a more
> "diplomatic" place than a technical mailinglist for a different project.
> 
> 
> One quick comment on Daves mail:
> > - Moving data; originally we'd looked at exporting from the 
> > cms into the filesystem, and having script that did a cvs 
> > add/remove/commit over the entire tree, into the main web 
> > CVS. This is still preferrable from an 'ease of rebuilding' 
> > point of view, but might be easier just to rsync the content 
> > from the filesystem of the cms machine to wwwmaster.
> 
> I think long-term, just dumping the files over is not a managable idea
> unless we have corporate committment for maintaining the backend.
> Because sure, the website will work, but if the backend goes down nobody
> will be able to use any of these uber-cool KB functions that's the whole
> reason it exists. It's more like a stop-gap solution.
> 
> (Bottom line, of course, I still think this should be *actually
> integrated* in the main website, and not just copied over from somewhere
> else. If possible. Again, see above point, it's way to early to actually
> comment on that now if the project is run that way.)
> 
> 
> //Magnus
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073




^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Integration Requirements
@ 2005-12-06 17:24  Josh Berkus <[email protected]>
  parent: Dave Page <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Josh Berkus @ 2005-12-06 17:24 UTC (permalink / raw)
  To: pgsql-www; +Cc: Dave Page <[email protected]>

Dave,

The below go far beyond "integration requirements" and stray into the area of 
dictating exactly how new web code should be built.  If you do that, you 
won't get any contributors.  Would you write WWW code on your own time if 
someone told you exactly what programming structures to use?

Integration requirements would be something like:
-- Needs to be able to run on FreeBSD
-- Must use the postgresql.org CSS, which is documented in __________ (note 
Magnus' comment on the lack of CSS documentation).
-- Can't have processor/ram requirements beyond ______________ unless a server 
is going to be donated,
-- Must be in one of the following programming languages: PHP, Perl, Ruby ... 
if in something other than PHP or Perl must be part of a long-term commitment 
for code maintenance.
etc.

> - Moving data; originally we'd looked at exporting from the cms into the
> filesystem, and having script that did a cvs add/remove/commit over the
> entire tree, into the main web CVS. This is still preferrable from an 'ease
> of rebuilding' point of view, but might be easier just to rsync the content
> from the filesystem of the cms machine to wwwmaster.

This isn't really practical for a KB or many other components, which need to 
be highly dynamic, not a bunch of static pages.

> - Navigation; Gevik was working on a tree-style thingy in PHP. Perhaps the
> CMS could export an XML file describing the navigation tree, which the PHP
> handler on the main website could use to generate it's treeview in dynamic
> mode. By accepting some sort of pointer to the currently selected node as a
> GET value, we should be able to make the tree fully mirrorable.

This is functional specification based on a lot of assumptions about the shape 
of the final interface, and I can't imagine it even being applicable to 
something I, personally, would build.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Integration Requirements
@ 2005-12-06 22:50  Dave Page <[email protected]>
  parent: Josh Berkus <[email protected]>
  0 siblings, 0 replies; 6+ messages in thread

From: Dave Page @ 2005-12-06 22:50 UTC (permalink / raw)
  To: Josh Berkus <[email protected]>; pgsql-www




On 6/12/05 5:24 pm, "Josh Berkus" <[email protected]> wrote:

> Dave,
> 
> The below go far beyond "integration requirements" and stray into the area of
> dictating exactly how new web code should be built.  If you do that, you
> won't get any contributors.  Would you write WWW code on your own time if
> someone told you exactly what programming structures to use?

I did. The last website. I am not dictating anything however - my comments
are a summary of what seemed to me to be the final agreement on what was
going to be done last time round. If you've got better ideas, let's hear
'em.

> Integration requirements would be something like:
> -- Needs to be able to run on FreeBSD
> -- Must use the postgresql.org CSS, which is documented in __________ (note
> Magnus' comment on the lack of CSS documentation).
> -- Can't have processor/ram requirements beyond ______________ unless a server
> is going to be donated,
> -- Must be in one of the following programming languages: PHP, Perl, Ruby ...
> if in something other than PHP or Perl must be part of a long-term commitment
> for code maintenance.
> etc.
 
- Must be written in PHP4, website template format, or a mix of the two.
- Must use the postgresql.org css if dynamically rendering pages in PHP.
- Must use 'friendly' URLs without POST or GET variables controlling
content, to allow mirroring (friendly URLs can be rewritten in GET
variables, per existing pages on the site).

>> - Moving data; originally we'd looked at exporting from the cms into the
>> filesystem, and having script that did a cvs add/remove/commit over the
>> entire tree, into the main web CVS. This is still preferrable from an 'ease
>> of rebuilding' point of view, but might be easier just to rsync the content
>> from the filesystem of the cms machine to wwwmaster.
> 
> This isn't really practical for a KB or many other components, which need to
> be highly dynamic, not a bunch of static pages.

It's going to be static if it's on the main website because the site is 100%
static. That doesn't mean that page updates cannot be reflected within 15
minutes or an hour or whatever.
 
>> - Navigation; Gevik was working on a tree-style thingy in PHP. Perhaps the
>> CMS could export an XML file describing the navigation tree, which the PHP
>> handler on the main website could use to generate it's treeview in dynamic
>> mode. By accepting some sort of pointer to the currently selected node as a
>> GET value, we should be able to make the tree fully mirrorable.
> 
> This is functional specification based on a lot of assumptions about the shape
> of the final interface, and I can't imagine it even being applicable to
> something I, personally, would build.

This is the design that Gevik proposed, discussed on -www (and -hackers
iirc) and previewed previously. I merely suggested a way for a CMS to
produce output to control the interface. Again, if you have other
suggestions about user interface and how that may be controlled, please
share them.

Unless someone actually proposes new ideas, I can only suggest how the
previous ones might be integrated with the website.

Regards, Dave 






^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2005-12-06 22:50 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-12-02 23:28 Re: Integration Requirements WAS: Launching PostgreSQL KB Project Mark 2 Josh Berkus <[email protected]>
2005-12-03 08:21 Re: Integration Requirements WAS: Launching PostgreSQL KB Project Mark 2 Dave Page <[email protected]>
2005-12-06 17:24 ` Re: Integration Requirements Josh Berkus <[email protected]>
2005-12-06 22:50   ` Re: Integration Requirements Dave Page <[email protected]>
2005-12-03 17:35 Re: Integration Requirements WAS: Launching PostgreSQL KB Project Mark 2 Magnus Hagander <[email protected]>
2005-12-04 01:24 ` Re: Integration Requirements WAS: Launching PostgreSQL KB Bruce Momjian <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox