public inbox for [email protected]
help / color / mirror / Atom feedRe: Integration Requirements
5+ messages / 4 participants
[nested] [flat]
* Re: Integration Requirements
@ 2005-12-06 17:24 Josh Berkus <[email protected]>
0 siblings, 1 reply; 5+ 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] 5+ messages in thread
* Re: Integration Requirements
@ 2005-12-06 20:26 Magnus Hagander <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Magnus Hagander @ 2005-12-06 20:26 UTC (permalink / raw)
To: Josh Berkus <[email protected]>; pgsql-www; +Cc: Dave Page <[email protected]>
> > - 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.
I agree that this isn't very practical - one of the reasons I didn't
like it in the first place. It has the one advantage that if this system
breaks, it doesn't brek the website. But designing for a system that's
expected to break doesn't seem like a very good idea.
Then again, "highly dynamic" does *not* necessarily mean you can't use a
set of static mirrors to do it. You just need to isolate parts of the
system, and put them in the right place. This is something that in my
experience most stock CMSes today to a bad job of, whereas custom ones
can do a better one.
(Heck, it's no big problem to serve a dynamic discussion site that
easily survives "the slashdot effect" off a single CPU 233MHz pentium
box with non-raid scsi disks. I've done it. You just have to accept
redifining "immidiate" as "1 minute". Not many sites require things to
be more dynamic htan that.)
//Magnus
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Integration Requirements
@ 2005-12-06 22:50 Dave Page <[email protected]>
parent: Josh Berkus <[email protected]>
0 siblings, 0 replies; 5+ 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] 5+ messages in thread
* Re: Integration Requirements
@ 2005-12-07 01:02 Josh Berkus <[email protected]>
parent: Magnus Hagander <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Josh Berkus @ 2005-12-07 01:02 UTC (permalink / raw)
To: pgsql-www; +Cc: Magnus Hagander <[email protected]>; Dave Page <[email protected]>
Magnus,
> Then again, "highly dynamic" does *not* necessarily mean you can't use a
> set of static mirrors to do it. You just need to isolate parts of the
> system, and put them in the right place. This is something that in my
> experience most stock CMSes today to a bad job of, whereas custom ones
> can do a better one.
Actually, it does. You can't do full text search with a static mirror.
You can't do bookmarking with a static mirror. You can't do article
feedback with a static mirror. Need I go on?
I'm talking about a real KB here, not just techdocs. A techdocs
replacement does fine as static content.
--Josh
--
__Aglio Database Solutions_______________
Josh Berkus Consultant
[email protected] www.agliodbs.com
Ph: 415-752-2500 Fax: 415-752-2387
2166 Hayes Suite 200 San Francisco, CA
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Integration Requirements
@ 2005-12-07 05:52 Marc G. Fournier <[email protected]>
parent: Josh Berkus <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Marc G. Fournier @ 2005-12-07 05:52 UTC (permalink / raw)
To: Josh Berkus <[email protected]>; +Cc: pgsql-www; Magnus Hagander <[email protected]>; Dave Page <[email protected]>
On Tue, 6 Dec 2005, Josh Berkus wrote:
> Magnus,
>
>> Then again, "highly dynamic" does *not* necessarily mean you can't use a
>> set of static mirrors to do it. You just need to isolate parts of the
>> system, and put them in the right place. This is something that in my
>> experience most stock CMSes today to a bad job of, whereas custom ones
>> can do a better one.
>
> Actually, it does. You can't do full text search with a static mirror.
> You can't do bookmarking with a static mirror. You can't do article
> feedback with a static mirror. Need I go on?
Of course you can ... you have the 'feedback' link go back to the master
server, same with the 'search link' ... we've been doing both on the
www.postgresql.org websites for ages now *shrug* The docs are
interactive, and we definitely have searching available ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2005-12-07 05:52 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-12-06 17:24 Re: Integration Requirements Josh Berkus <[email protected]>
2005-12-06 22:50 ` Dave Page <[email protected]>
2005-12-06 20:26 Re: Integration Requirements Magnus Hagander <[email protected]>
2005-12-07 01:02 ` Josh Berkus <[email protected]>
2005-12-07 05:52 ` Marc G. Fournier <[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