Re: [Firebird-website] [Firebird-general] Re: Fb Website

[tjelvar e. <tj...@fa...>]

Hi all,

> 1. Site search could be actually faster from flat files than from
> database if there isn't any full-text that could work with Firebird.

a) I'm not a drupal evangelist, but it does have fulltext-search in  
the framework,
others may have too - don't know about BW.

b) Home of firebird - powered by flatfiles. True irony...

> 2. We don't need blogs, forums or extensive news on Firebird website.
> There are other sites that do them all already. Firebird website is  
> for
> documentation, downloads, link "address book" to other resources and  
> for
> Firebird project members (developers, docwritters, QA etc.) to help  
> them
> do their work and to potentially attract new contributors. It's
> definitely not a community site and shouldn't become one. It should  
> be a
> display case for the project, static and tightly controlled.

I do respect your opinion, and this is where the discussion should  
start.
What to put in and what it should be.
My original post, which started of this discussion as i belive, was  
based
on a reflection that A.W Harrison wrote that the interest for firebird  
at
last conference where null.
Your reflections around "definitly not a community site" should be  
given a second thought.

> 3. As wiki goes, it doesn't necessarily needs a database as backend,  
> and
> we could probably use already existing one or use one provided by
> SourceForge anyway, and soft-embed it into our site.

I'm not sure what you mean with soft-embed but it sounds as dependent
patch, and with a mysql-prefix. Hands down here.

> 4. Using a database would force us to work with site content over the
> web (or other) interface, which is unnecessary and in fact
> counter-productive in our case.

Pavel, please explain. I'm not sure which work you're refeering to,
(doucment translation)?

What's the benefits of the current setup? Those could/should be  
respected.

Any web-interface could be coupled to dav or svn it that's the subject.

For documentation,The database doesn't/shouldn't contain web-dependent  
formatting,
markdown is there, others too. See previous post.

(And are human translations effective - couldn't google do the work)

>> WHy would you not use Firebird .....

> Database is a database, it doesn't matter which one. We use Firebird  
> at
> our tracker, and as painless it is, it's still just a necessary evil
> (JIRA doesn't work without a database) that adds to administrator's
> responsibilities.

I'm dizzy. Pavel, I may misundersand you, but you sound counter  
database,
and counter web. I'm the opposite and have delivered stable  
webapplications
for years to clients. One use firebird, (other do use mysql).

I do belive however, that the tracker should be treated as another  
animal,
not as part of a new homepage.

> Any solution for our new website should have
> zero-maintenance and nearly zero-complexity for backup/update/upgrade.
> The fever "working" parts it would have, the better.

I'm suspecting a serious problem with the mainainence of the tracker
and possibly any new site. It's a less glorious work and the one  
willing to
take the responsibility should earn the accumulated donations on yearly
basis, my five cents..

Regardning the discussion of backup of firebird, my experiences are  
just fine,
(it's not tera-bytes). I was lead to belive that firebird was the  
database that didn't
need a dba?? ;-)

Finally I belive we're not getting anywhere - I'm not happy anyway.

Thing are compex. Yes...
Efforts have been made. Yes.... ..but any progress?
Do we wan't firebird to be fairly unknown? Maby. It's convinient in a  
way.

But if firebird is an true open source project, the community should  
be heard
and invited.

PAUL, Are you still the official Coordinator of firebird documentation  
project,
share your thoughts!

respectfully,
/tjelvare