Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42F873D4.5080108@apache.org>
Date: Tue, 09 Aug 2005 10:13:56 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Repository browser: Daisy or Lenya ?
References: <42F7482A.8060201@peppersauce.org>
 <42F750FC.9000207@apache.org>	 <4998884405080811137ca80853@mail.gmail.com>
	 <42F7BC82.40701@peppersauce.org> <4998884405080819267ac474e7@mail.gmail.com>
In-Reply-To: <4998884405080819267ac474e7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tim Williams wrote:
> On 8/8/05, Anil Ramnanan <list@peppersauce.org> wrote:
> 
>>Tim Williams wrote
>>
>>
>>>I just went back to the Anil's original proposal and it calls out
>>>Lenya specifically (see below).  I went back and looked because I
>>>don't understand what exactly this does.  I thought the general
>>>approach for "integrating" backend repositories was the use of
>>>locationmap, thus not so much integrated as "linked to".  Is this
>>>"Repository Browser"  a way to "browse" the repository then create a
>>>location match based on what is found?  I've been a way for a couple
>>>weeks now and am slowly catching up so I apologize if I missed
>>>something.  Can someone give me more details of exactly this is to do?
>>>Thanks,
>>>--tim
>>>
>>>
>>
>>The "Repository Browser" as I saw it would be a view in the Eclipse
>>plugin that would allow the user to browse the documents in a particular
>>repository. The user would then select the document that they are
>>interested in and drag it to the locationmap where it will create the
>>appropriate entries for it. The browser should be bale to support the
>>browsing of multiple repositories.
> 
> 
> I suppose it's the selecting *the* "document that they are interested
> in and drag it to the locationmap" that's the question.  Maybe an
> easier question would be is this tied to a real-world use-case? 
> Please explain that.  

(I'll jump in here because this is driven by my own use case, however I 
know Anil also has his own, he'll let us know about it if it raises more 
issues)

I do voluntary work for a charity (http://www.cawd.net). This charity 
does work in a rural village in Nigeria, they have installed a computer, 
satellite link and generator (they don't even have piped water, but they 
have an Internet connection!).

They use the CMS to generate content of use to their community, to the 
charity as a whole, and to the wider Nigerian communities. There is a 
whole load of information that is relevant to different groups.

Because the Internet is so expensive (running a generator and paying for 
bandwidth is expensive to people who live on less than one US$ a week) 
we need to provide offline access to the content. Enter Forrest.

Now there are around 2000 pages of information in this CMS at present. 
Some of of no interest to farmers, some are of no interest to school 
teachers, some are of no interest to nurses etc. We don't want to go and 
dump all 2000 pages on these (generally computer illiterate users) and 
expect them to find what they want. Instead we want to create custom 
publications for them that contain only the information they are 
interested in.

So, we need an interface for our partially trained computer operator in 
the village to use to create these publications for other Nigerian villages.

> I just dont' currently get the benefit over just
> a locationmap editor.

It's a GUI to the locationamp editor - (some) users need GUI's.

>  I guess I view folks using respositories for
> all (e.g. **.xml) or at least a subset (*/sports/**.xml) of their
> content rather than just cherry-picking (e.g.
> /sports/august/08/story1.xml) one or two documents from different
> locations.

You are assuming that the content in the source CMS is well ordered and 
that there is no overlap between sections. For the first point, even in 
the most strictly controlled CMS with the most rigid of processes in 
place you will still find someone mis filing something. For the second 
point materials on how to treat a sprained ankle are relevant to the 
sports groups as well as the nurses, but how to treat a broken leg 
requires different content for each group, yet it is likely the content 
will be located in the same section of the repository.

My vision (possibly out of the scope of GSoC) is to have an intelligent 
match generator. So the first time you drop a document it creates a one 
to one match. Next time you drop one it creates a wild card match and 
removes the original. When you drop in an excpetion to the rule it spots 
it and places a one to one match in the right location.

Of course one should be able to drag and drop a folder too.

>>Here is a rough outline of how it should work.
>>
>>        Repository View
>>                     |
>>       Repository Interface
>>                     |
>>         -------------------
>>         |            |               |
>>    Lenya      Daisy      Slide
>>
>>
>>
>>The Repository View is the actual View in Eclipse which shows the
>>documents available in that repository. This is where the user can
>>select the document to be included in the locationmap.
> 
> 
> There's *the* document again.  When I'm interested in integrating a
> backend to Forrest I'm looking at, for example, all xml.  Maybe all
> xml (**.xml) getting matched from Slide/Xindice/Berkeley DB XML for
> example.  For this, if you're giving me a locationmap editor already,
> how does the Repository View help?

It's a GUI to the locationamp editor - (some) users need GUI's. Using 
this GUi the user need not understand how to compose the matchers.

Ross