firebird-website

[Firebird-website] (no subject)

[<pc...@at...>]

>From ???@??? Sat May 12 17:44:46 2001
Received: from ctb-mesg1.saix.net ([196.25.240.73]) by pop.atlas.cz  with Microsoft SMTPSVC(5.5.1877.357.35);
	 Sat, 12 May 2001 17:00:17 +0200
Received: from johan (ndf53-06-p120.gt.saix.net [155.239.72.120])
	by ctb-mesg1.saix.net (8.11.1/8.11.1) with SMTP id f4CEuun28126
	for <pc...@at...>; Sat, 12 May 2001 16:56:58 +0200 (SAT)
From: "Gerhardus Geldenhuis" <fl...@gl...>
To: "=?US-ASCII?B?UGF2ZWwgQ2lzYW8=?=" <pc...@at...>
Subject: RE: [Firebird-website] Some ideas
Date: Sat, 12 May 2001 17:02:12 +0200
Message-ID: <MLE...@gl...>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <3AFC1B78.29515.1F4CED0@localhost>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Return-Path: fl...@gl...

Hi

I agree in principle to all the ideas you proposed.
I just feel that the site does have the potential
to become very big. We should in my opinion right
from the start use a tool to do management. I am 
not familiar realy with such tools so I dont 
know what is best. It is easier to start right
and with a learning curve than to go over to a
tool to manage the website once we realize we cant
cope any longer. Such a tool would also enable us to,
with more willingness consider new ideas that
would entail extra work, because it would not envolve
that much extra work. I have something in mind
but I think we should first agree to use something 
like that or not.

Groetnis
Gerhardus

[Firebird-website] Deciding tools?

[Helen B. <he...@di...>]

At 05:57 PM 12-05-01 +0200, Gerhardus wrote:

>Hi
>
>I agree in principle to all the ideas you proposed.
>I just feel that the site does have the potential
>to become very big. We should in my opinion right
>from the start use a tool to do management.=20

Whilst I agree that a toolset is going to be needed, I think that FIRST i=
t has to be determined what sorts of things you need tools for, how the n=
avigation works (which Pavel touched on when mentioning drill-downs, etc.=
) and, above all, what the site structure ought to be.  *Then* one looks =
for tools (FREE!) that can do what's wanted.  IOW, this is a normal devel=
opment project from requirements-taking through to implementation and gro=
wth...

Step 1:  What do we need to build?
Step 2:  What's needed to build it?  (tools, personnel, source materials)
... more bits ...

Step n:  What tools do we need (have already, can get easily, have people=
 who can test-drive them, can fit developers' platforms as well as the ho=
st platform, etc.)
Steps n..... Build, implement, test, maintain...

A evolutionary process during building and implementation is going to pro=
duce more satisfactory results than a prescription, too (spoken from expe=
rience).  Need to be able to try test pieces out on the users.

Just more thoughts on the pile at the moment.

Cheers,
Helen

All for Open and Open for All=20
InterBase Developer Initiative =B7 http://www.interbase2000.org
_______________________________________________________

RE: [Firebird-website] (no subject)

[Kaputnik <de...@ka...>]

Hi,

a friend of mine is building very dynamic html-pages with mySQL and php4. It
is very easy to maintain, except for the lack of FK-constraints in mySQL
:-))
he has a nice framework, some HTML-Templates, and a database containing the
content.
If some article has to be put up, it is simply stored as row in the
DB-table.
the complete navigation is done with php, and all links are built
automatically...so, with a small db-tool in delphi (which I built for him)
every dummy could add a new article or complete new content including new
navigation-links (provided, he has db-access)-
I for myself would very much like to have the FB-website put up with either
php4 and FB as backend or even Delphi (isapi) and FB-DB as backend.
I know, that putting an FB-server up on the sourceforge-site would be
difficult, but I definitely can spare a dedicated FB-server here at my site
(connected via switch with 100MBit/s to the internet), on which the php4 on
sourceforge could have access to.
Putting up the php4-framework is only a matter of time and money (i have to
pay him, even if he is my firend, but would do it, if you like the idea).
This way, the FB-website would be the best marketing for FB itself, as the
site would have a small "Built with FireBird" tag :-))


P.S. I definitely hope, that the talk in this new list will be productive,
and everybody is friendly to the others ;-)
My 2 cents...

CU, Kaputnik
(Nick Josipovic)

ni...@ka... <mailto:ni...@ka...>
ka...@ka... <mailto:ka...@ka...>
--------------------------------------------------------------
superior Client/Server programming:
www.IBObjects.com <http://www.IBObjects.com>
a nice tool for Interbase:
www.InterbaseWorkbench.com <http://www.InterbaseWorkbench.com>



> -----Original Message-----
> From: fir...@li...
> [mailto:fir...@li...]On Behalf Of
> pc...@at...
> Sent: Saturday, May 12, 2001 5:58 PM
>
> Hi
>
> I agree in principle to all the ideas you proposed.
> I just feel that the site does have the potential
> to become very big. We should in my opinion right
> from the start use a tool to do management. I am
> not familiar realy with such tools so I dont
> know what is best. It is easier to start right
> and with a learning curve than to go over to a
> tool to manage the website once we realize we cant
> cope any longer. Such a tool would also enable us to,
> with more willingness consider new ideas that
> would entail extra work, because it would not envolve
> that much extra work. I have something in mind
> but I think we should first agree to use something
> like that or not.
>
> Groetnis
> Gerhardus
>

RE: [Firebird-website] (no subject)

[Pavel C. <pc...@at...>]

Hi,

I agree with Helen that we should put first things first :) So we 
should first decide about requirements to the site, next to its 
structure etc. But we can also summarize the facts, to set up 
margins for decisions.

So, few facts:

We have private MySQL database + PHP4 at SourceForge. I don't 
know the limits for database size (should we ask SF staff ?). We 
have cca 100MB web space here (more could be negotiated). 
Everyone in project can access that space through SSH/SCP (it's 
a great plus). The Apache server is not overloaded (of course, it 
have a peaks, IMHO mostly due maintenance) and average 
response time is acceptable if not very good (and should be in the 
future, because VA Linux care about this and upgrade hw when 
necessary). Also connectivity to the NET is very good (check for 
yourself the SF doc page about that :). I'm not sure about backups, 
so we have to do that ourselves for web space and for database too 
(web is in CVS, so it's in safe if someone keep backup of daily 
CVS tarballs, BTW did that someone ? I've few whole cvs tarballs, 
but I don't do that regularly. It's general admin issue!!!). I do 
database dump + backup every two weeks or so. We can use CGI, 
but I'm not sure about the policy. I guess that CGI should be at 
least reviewed by SF staff, because they care about security. 
Actually, I didn't investigate about CGI. We CAN'T set up another 
database (FB) or environment (we should have standard Linux 
tools, like pearl, python, sending mail etc. but I don't know the 
details), nor reach any service outside the SF domain from our web 
(php), so plans about database at our own server are not doable. 
SF staff is very careful about security (and that's good). We can 
also get the VHOST, i.e. our own domain for web site. All in all, the 
quality of service at SourceForge is superb (to some extent :).

It's a fact, that our web could be anywhere and from some angle, it 
could be better if it would be, but... The host'll have to:

- good connectivity to NET, guaranteed uptime (TBF)
- secure access for many people (web team) and admin tools at 
their disposal
- regular backups
- tools to run the site (php, zope, whatever)

Some notes about tools and infrastructure: It should (or shall?) be 
open source, so we can tweak them and adapt them to our needs 
as their change. And yes, it would be nice if we would be able to 
eat our own dog food (FB).

To Nick Josipovic: I'm not against your proposal (it's great), but 
take to consideration what I wrote above.

Best regards
-- Pavel

[Firebird-website] Bug report re Bug reports

[Helen B. <he...@di...>]

Pavel,

Currently there seems to be no link to the closed & open bug lists from t=
he site.

Linking to it via its url works;  but, once you select one or the other r=
eport, you can't get back to the launch page.

More...

The layout of the page is much nicer now, IMO.  Just a couple of points a=
bout the items in the top menu:  "Recommend" not "Recomend";  and "Other =
downloads" not "Other download".

Cheers,
H.

All for Open and Open for All=20
InterBase Developer Initiative =B7 http://www.interbase2000.org
_______________________________________________________

RE: [Firebird-website] (no subject)

[Pavel C. <pc...@at...>]

Hi,

On 13 May 2001, at 1:58, Kaputnik wrote:

> If sourceforge offers mySQL for the FB-website, lets do the website still
> dynamically in php and mySql, and after FB1.0 porge VALinux as much as
> possible to install FB on the webservers :-))

Yep. Because that the best solution would be some db-backend 
abstraction layer used in php solution. IFAIK there are some for 
php already available.
 
> The codebase for dynamically building the stuff in mySQL is already
> programmed, and I could put up some agreement with my friend to get the
> source...he is eraning his money designing dynamic webpages from db's, so I
> think, it should be pretty stable....

It would be great. The open source solution (even GPL) would be 
best, because in that case we would be able to put it in our CVS.

> A very large plus for any dynamic system is, that even the most no-html
> person (myself for example) could add content to the site simply by using
> some db-aware client app (content manager) and the php builds the structure
> and sites on the fly....

That's the intention. But I'd like rather go with web-based content 
manager than with client-app. But it should doable without much 
work (there are some OS systems to generate php admin code 
from db structure).

> btw, if you need more webspace for downloads or large articles, I have
> several gigs to spare, and they are pretty fast at least for european
> visitors (100mbit/s)....

Thanks for offer, it's noted for future :)
 
> for the future, I tend to think of mirror-sites anyway.....have a start-page
> like PostreSQL, and redirect the visitors to the appropriate
> mirror-server....another plus for a dynamic webpage.....mirrors can be
> synchronized in both directions via db-replication :-)))

Ahh, mirrors! How could I forget them :)

Regards
-- Pavel