[Barrie, I hope you don't mind that I put it on the list, the more people
contribute the better the outcome :)]
> Hi Stas, sorry it took so long to get back to this :-/.
it's not late al all, really ;0) we have years to come to work on this
project.
> Some minor feedback. I could see an additional "books", a
> troubleshooting reference (as opposed to a guide, like part VI). Many
> service organizations have large manuals that are essentially a
> compendium of failure modes and instructions for how to troubleshoot
> each one. Seems like a searchable database of error messages, etc.
> might be a boon to the community. Given some keywords or a message, you
> could find (in one query) articles in the db *and* mailing list messages
> related to them. I could see the usual knowledge base type rank this
> article.
Something like this: http://perl.apache.org/guide/troubleshooting.html ?
The problem with DB, is maintence. When it's flat, people read mostly
sequentially, point out and fix problems. When it's in the DB, most of the
items would hardly come up and it's easier to have stale data in there.
Especially when you knowledge base getting big.
It's also hard to follow the evolution of the DB, since you don't see the
changes like you do with flat files, as they change with CVS commits.
I think I need more convincing points to decide to make it as DB.
> Hmmm, since you've already pointed out that printability is not the
> primary goal, I wonder if we should just take AxKit and it's nascent CMS
> and start building a knowledge base? The book format is nice for
> getting spun up to speed, but the knowledge base interface is what might
> actually cut down on list traffic.
Well, if you don't get to work with XML directly. I sure thing dislike
maintaining simple documenents in XML. Since you have to use some web
interface to edit the documents, you have no power of editors like
vi/emacs, which makes the work much harder.
This doesn't mean that you cannot split the flat files into items and have
a parallel interface for search. In fact Matt has already done this. Since
http://perl.apache.org/guide/troubleshooting.html is all simple items,
it's very easy to itemize it.
Also don't forget the split version of the guide, used by the search
engines: http://perl.apache.org/guide/index.html#search
> I could even see a search interface on an email address, so when you
> see a FAQ pop up on-list, a simple forward to [EMAIL PROTECTED] or
> something would do a search and send you back a message suitable for
> forwarding to the original poster or something.
This would be a very sensitive change. You don't want to AI replies end up
on the list, since they won't be correct all the time. But if you only
reply to users, humans will still reply, so what's the point :) May be
having posts like:
!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!
!!!!!! THIS IS AUTOMATIC GUESS !!!! IT CAN BE WRONG !!!!!
But definitely an idea to consider and explore.
> Kinda like the IRC bot purl.
Heh, I'd love to play with infobot (==purl) in the real world. I think
Kevin said that it's ready for working outside IRC.
One of the cool things I thought about is replace Doug's presentation
'command server' protocol with 'infobot' loaded with mod_perl factoids.
This will make the presentation even funnier, and we can actually put the
bot online for others to re-use!
> The other "book" would really be a set of how-tos for getting various
> systems (templating engines, CMSs) up and running. That's probably a
> lot like your C.IV, but the "howto" format has become a meme with a lot
> of understanding in the community.
Sure, there is no limit on how the third book should look. As long as it's
manageable and useful for users. The first two books will play it strict.
The third one is very flexible.
> I guess I really see this as more of a "mod_perl guide plus knowledge
> base" implementation than a "three volume book set", with the
> pumpkings being "series editors" for knowledge base articles, and the
> pumpkins could easily drag in "tech editors" from the appropriate
> systems if need be.
Yup, exactly. seems very exciting if actually get to implement it. Then
the world domation will be finally a next chapter. :)
> Just some pseudo-random ideation boiling down to "let's use mod_perl
> to buils a knowledge base" both to demonstrate it's power and to serve
> the community.
I like the idea!!!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
