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

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

Pavel, thank you for explaining things.
I have no objections in what you're saying.
It's just that this discussion originally started as a reply to
AW Harrison, "absolutely no interest for the firebird", see post 10615  
at firebird-general.

As stated previously, all my respect to everyone involved in creating  
and maintaining
firebird, period. IF we all, customers, end users, and docteam can  
gain of a
new site I see good reason for such an initaitve.

Have a good day, :-)
//tjelvar
19 nov 2009 kl. 12.14 skrev Pavel Cisar:

> tjelvar eriksson napsal(a):
>> 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...
>
> Technology should serve US, not by other way around. For content and
> services that we want on the Project's website it's best to be  
> served as
> static pages, as there is almost NO dynamic content. For practical
> purposes, the pages are divided into snippets (header/footer, menu  
> bar,
> sidebar, main page content) that are stored separately and assembled  
> by
> page glue code. Except few information areas that are repeating  
> patterns
> (list of web resources, news, sub-projects and members information)
> nothing really calls for a database. Database would be an overkill for
> this, period. These few info bits that *could* be served from database
> are few, so having them in "data text files" is cheaper and quicker.
>
> We DO use Firebird as backend on our TRACKER. We even adapted JIRA to
> work with Firebird as it wasn't originally supported database. But  
> that
> was justified because tracker software needs a database backend if it
> should scale and work efficiently. Our website does not. I would agree
> to use a database if we would implement some forum facility on it or
> something that would have a lot of dynamic content with few data
> patterns, but it's NOT this case.
>
>> 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.
>
> As far as I remember, nobody ever expressed any problems with general
> concept, content and target audience for Firebird Project website. All
> objections were always targeted to site *structure* and *design*.
>
> For the record, the Firebird website served also as community portal
> (with CMS and db backend) many many years ago, when both project and
> community were young and relatively small. But these days are over.  
> Even
> if we would like to add blogs, extensive news, forum etc. to our site,
> we would be just late to the party as all this is already covered by
> many thriving sites. There is no point to compete with them, as *our*
> duty is to work on Firebird and related sub-projects, and to help  
> users
> to get and learn our products, not to operate the community portal.
>
>>> 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.
>
> It means that it would work on its separate site, but we'll link to it
> as an integral part of the site (the design could be even united).
>
>>> 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)?
>
> No, to provide content, generally. That's what we do.
>
>> What's the benefits of the current setup? Those could/should be
>> respected.
>
> I explained it earlier, it's dead simple for those who work with the
> content although we all use various OSes and favour different tools,  
> and
> it's literally zero-maintenance for administrators and almost
> zero-configuration (you can get your own local copy up and running in
> few minutes). We like it that way.
>
>> Any web-interface could be coupled to dav or svn it that's the  
>> subject.
>
> Yes, it could, but why, when the current one is much simpler and works
> perfectly?
>
>>
>>> 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.
>
> Nope, I'm just practical. I do QA in Firebird, that's my primary
> objective. I and Helen work as webmasters because somebody has to.  
> We do
> it from the beginning, and over the last nine years nobody ever
> expressed any real interest to join us (but we heard plenty of advices
> how we should do it). I take care of PHP code and low level plumbing
> (except the Foundation sub-site which is fully under Helen's control),
> Helen looks after the general content and last years also after the
> visual design. Few others (including me) work with the content in  
> their
> areas of interest / parts of our site (sub-projects). We have other
> duties, but we also do some web publishing, and we want it dead simple
> for us. That's it. Maybe Helen could appreciate a full-blown CMS for  
> the
> occasional news and download pages that represents the main portion of
> what she does frequently, but I doubt that.
>
>> Thing are compex. Yes...
>> Efforts have been made. Yes.... ..but any progress?
>
> Things are not complex, they're dead simple. The problem is that we  
> have
> many talkers but few workers that are already overloaded. No wonder  
> that
> progress in certain not-so-vital areas is slow (or do you prefer fancy
> website instead new stable FB delivered on schedule?).
>
>> But if firebird is an true open source project, the community should
>> be heard
>> and invited.
>
> Community is always invited and heard, but universe likes to grant
> wishes to those that contribute for real to make them a reality.  
> Talk is
> cheap and candy grows on trees only in fairy-tales. Unfortunately,  
> many
> people (even grown-ups) tend to live in fairy-tales. Just walk through
> the archives, and you'll see. If Firebird Project would be fueled by
> good advices given from the distance, then we would have enough in  
> bank
> to pay our developers for rest of the century.
>
> best regards
> Pavel Cisar
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Firebird-website mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-website