lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <simon.willna...@googlemail.com>
Subject Re: [lucy-dev] Generalize Tutorial for multiple host languages
Date Fri, 05 Nov 2010 15:39:08 GMT
hey Marvin,

On Fri, Nov 5, 2010 at 12:30 AM, Marvin Humphrey <marvin@rectangular.com> wrote:
> Greets,
>
> Most of Lucy's documentation has been written so that it will work with
> multiple host languages.  To the extent possible, class descriptions, method
> descriptions and so on are host-language neutral -- only code samples need be
> customized.
>
> Our multi-chapter Tutorial is still Perl-specific, however.  It would be great
> if we could adapt it for use across multiple host languages -- but right now,
> it has dependencies which will not be available for every language/platform
> combination.
That would be absolutely awesome I am not really into perl (shame on
me I know) and something like that would definitly help me a lot. I
find myself in the situation where I am gonna need it sooner or later
:)
>
> Currently, the tutorial builds sample applications designed to be used in a
> web context using an HTML presentation of the United States Constitution as a
> corpus.  For HTML parsing, CGI processing, and paging through results, we use
> dedicated Perl modules, some of which belong to the Perl core and some of
> which must be obtained from CPAN.
>
> To eliminate these dependencies, I think the Tutorial should be simplified to
> build a command-line app, and the corpus should be changed to plain text.
> Every potential host language has basic file and directory manipulation
> capabilities; it should be possible to generalize the tutorial prose so that
> it can work with all of them without modification.
+1
>
> Additionally, by eliminating those CPAN prerequisites entirely, we skirt the
> issue of dependency licensing.
awesome again!
>
> The only downside is that easily-customizable sample applications are
> compelling (see Ruby on Rails), and we'll be taking our "instant web search"
> kit and making it less handy.

I know it would be an overhead but could we maintain that aside of the
getting started example?

simon
>
> We face a similar challenge with the CustomQueryParser Cookbook entry
> -- which uses Parse::RecDescent -- but that will be harder to resolve.  I'm
> not sure what to do about that one, except possibly remove it from the
> distribution and publish it elsewhere as an independent article.
>
> Marvin Humphrey
>
>

Mime
View raw message