[OPEN-ILS-GENERAL] In the pipeline

[Mike Rylander]

On 10/27/07, Dan Scott <denials at gmail.com> wrote:
> On 21/06/2007, Mike Rylander <mrylander at gmail.com> wrote:

[snip]

> > After we get to that point, we have big plans for the 1.3 dev branch
> >
> >   * full I18N
> >   * tons of OPAC enhancements (many of which will move back into 1.2)
> >   * Java client (and probably server) support
> >   * simpler index configuration
> >   * full NACO-normalized authority linking and tracing
> >   * hold freezing
> >   * faceting and new browse interfaces
> >   * exposing of the advanced search syntax
> >

[snip]

>
> I'm going to poke again -- apologies :)
>
> Since we got the 1.2.0 release out in September (huzzah!), naturally I would
> expect to see the 1.4 release pushed out from a Fall time frame to a Winter

I think (and hope) late fall or very early winter (IOW, Dec) is possible.

> time frame. Are we still good with the plans for the 1.3 development branch?
> Certainly the i18n support is coming along, the Java client / server support
> is pretty much in place, a bunch of the hold freezing stuff has been going
> into trunk, and there has been some movement on the acq/ser system (albeit
> not much code that people can play with yet).

We hadn't planned on branching 1.3 from trunk, just tagging it as it
progressed to stable-ish points along the way to a 1.4 feature freeze.
 Is there a benefit to having a branch other than trunk to develop
towards 1.4?

> On the simplified index
> configuration, I'm not sure if we were aiming higher than simply dropping
> the stopwords (which certainly was a big step forward).

I'd like to get a basic interface put together to manage the indexable
data extraction (what librarians call indexing), but I think Evergreen
2.0 + Postgres 8.3 will be when database level index setup management
will happen.  By that I'm referring to adjusting stemming, stopwords,
in-db thesauri (different than authority), query re-writing;  adding
parsers and locales; nls sorting -- all that good stuff.

> I'm also not sure
> where we are with the NACO-normalized authority linking and tracing work; I
> imagine this would sync up with whatever authority management interface we
> would be able to develop.

The NACO normalization functions have bee written, now we need to find
the best way to pull the bib and authority records apart for linking.
The actual pulling apart, of course, will be MARC-variant specific, so
I'd like to design a generalize structure in the same spirit as the
metabib.*_field_entry tables.  I have some ideas on that, and we may
be able to reuse some of the stuff I did for the XSLT-based experiment
(which may not have made it here).

> I confess to not knowing what "exposing the
> advanced search syntax" is... just documenting the current OPAC search
> interface (as I half-assedly did earlier this week)? Or documenting REST
> interfaces & unAPI for generating XML search results / MARC record export /
> other hidden gems? The latter would certainly be cool.
>

The advanced search syntax a google-esque tag-based system for
building complex queries.  The slimpac supports it now, but the main
opac does not.  It looks like:

title:harry potter author:rowling sort:title sort_dir:desc site:arl

Extending/modifying that to be more like cql or creating a cql
transformer for that syntax (which IMO is simpler) is a goal I have.

Documenting all of the extended interfaces would be cool as well.

> I'd also like to point out that the "Development Roadmap" linked from the
> front page of the wiki
> (http://open-ils.org/dokuwiki/doku.php?id=feature_list ) is
> rather dangerously out of date for those who might not be following the
> mailing lists. I was promised flying cars, dangit!
>
> Would this be a good time to revisit the roadmap and sync up the wiki entry
> with reality? Ideally, each entry in the roadmap would link to a fuller
> description of the plans for that particular entry (so that those with the
> required chops could jump in and help push that piece of the project
> forward).

I would not stand in the way of such a plan.  ;)

>
> Perhaps we could set up a recurring monthly or bimonthly appointment to
> revisit the development roadmap and adjust it back to reality... You never
> know when someone will have been beavering away on a project on their own
> for a while and suddenly have a telephony system to merge into trunk :) I
> realize this isn't a particularly agile approach, but communication (within
> the development team, within the community, and externally to those
> interested in the project) is a huge piece of any open source project, and
> until there are more community members helping us with that communication
> (here's another call for an "Evergreen Weekly News" writer and for
> http://open-ils.org/blog writers), we're going to have to keep shouldering
> that burden.
>

Sounds good to me.  I think whipping the roadmap into shape first will
help a lot with directing the broadcast update.

Thanks for poking.

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com