Re: looking to volunteer my services

On Wed, 30 Jan 2002, Uri Guttman wrote:

> maybe you are. :) categorizing books is non-trivial. MRE is both regular
> expressions and perl as well as other languages and programs. some perl
> books are newbie only, some newbie to mid, some mid to expert,
> etc. other books we would include might have odd categories or
> types. how would you list design patterns (i still need to read it)? so
> a simple category search is not enough. we may need to have several axes
> for typing books: langs, CS area, general area, expert level, etc with
> multiple values (but from a fixed list) allowed in each. then the search
> engine page could have each axis as a multi checklist which makes it
> easy to select books.

I was thinking that these could all be just 'categories', in sort of a
tree system:

 Technical -> Programming -> Perl
 Technical -> Programming -> Regular Expressions
 Technical -> Design -> OO
 Non-Technical -> Design -> Writing
 Fiction -> Erotic -> Furry fan fic (yeah, gotta have lots of that ;)

Expertise level would probably be a separate (and optional) attribute.

The problem with the multiple axis method you're suggesting, IMHO, is that
it requires us to be adding new axes on a fairly regular basis, because
existing axes won't be suitable to new types of books.  The axes we use
for programming books aren't necessarily appropriate for fiction which
aren't appropriate for non-fiction historical books etc.

> i am agreeing to that. can't you read?!! :) i said popular with the perl
> community, not necessarily a perl book. just that all perl books get in
> no matter what as it is the PERL community books page.

Ah, I see.  But why would the committee ever reject something is my
question.  Besides weeding out duplicates, which may not be a big issue
with a decent search engine.

>   DR> Maybe.  If we are using use Perl's user info we can direct them to their
>   DR> use Perl user page.
>
> that works.

Or, on reflection, we could store some 'books.perl.org'-specific info
locally as well.  Hopefully we'll be able to pull ad-hoc user info from
use Perl as needed for display on books.perl.org.  At least that's what
Chris Nandor and I were theorizing about.

> this is sounding more like a real plan than pie in the sky. i think we
> can start moving forward on the various pieces. what would be our next
> (parallel?) steps? DB schema (i added search term axes here)? web
> design? use perl integration?

Here's what I see as being the next things that can be worked on.

- UI design.  sfritz volunteered for this.

- DB design.  This is partly there but may change depending on how we
decide to categorize things.  So let's talk about categorizations.  Other
than that, I think what I have is fairly good, and I don't see a lot of
debate here since its just a small number of tables and this isn't rocket
science.

- use Perl integration.  Basically, use Perl (i.e. slashcode) needs some
sort of machine-usable interface for doing the following:

-- Given a username/id/something and a token, saying that this is or is
not a valid token.  Presumably, this token will be set by the use Perl
login mechanism as a cookie for the 'perl.org' domain, so we'll be seeing
it at books.perl.org

-- Given a username/id/something returning relevant public user info.

Then we'll need a client-side piece for this as well, which should cache
things heavily so as not to beat the crap out of use Perl.

I can work on this but not right now so if there are any volunteers I'd be
happy to help in a mentoring way, but writing large chunks of code is out
for the moment.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/