Repository browser: Daisy or Lenya ?

[Anil Ramnanan <li...@peppersauce.org>]

Since I have to develop a repository browser I believe that my choices
are Daisy or Lenya. Which of these do you think I should be using ? As
Ross said, the Daisy plugin is fairly complete so I am currently leaning
in that direction.


Anil.

Re: Repository browser: Daisy or Lenya ?

[Ross Gardler <rg...@apache.org>]

Tim Williams wrote:
> On 8/8/05, Anil Ramnanan <li...@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

Re: Repository browser: Daisy or Lenya ?

[Tim Williams <wi...@gmail.com>]

On 8/8/05, Anil Ramnanan <li...@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 just dont' currently get the benefit over just
a locationmap editor.  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.

> 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?

> The Repository Interface provides the view with the list of the the
> documents available. The interface will be built so that it you can plug
> in a number of different repositories. This way the Repository View
> would be independent of the repository being used.

That's good stuff. 
 
> Daisy was suggested because there is a working Daisy plugin that allows
> you to retrieve documents from a Daisy repository.

That's cool, I don't doubt you'll implement it in a repository generic
way, my questions are purely out of ignorance, I just don't
immediately get what the benefit is -- I'm not doubting whether it
exists, just trying to understand it.  My reference to the proposal
was more nit-picking since the question came up than anything else.
--tim

Re: Repository browser: Daisy or Lenya ?

[Ross Gardler <rg...@apache.org>]

Anil Ramnanan 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?

Anil is working on an Eclipse plugin that provides GUI tools for 
building Forrest sites. He is *not* working on the core of Forrest 
itself, which, as you say would actually process the content as it doe now.

> 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.

Yes.

Note that "appropriate entries" is complex. It is not just a case of 
adding a one on one matcher, although this will do on the first iteration.


> The browser should be bale to support the
> browsing of multiple repositories.

This is very important. It is interesting that TIm picks up on the fact 
that the original proposal named Lenya, that was a mistake on my part. I 
should not have allowed the specific repository to be named. I was 
hoping that more would have happened with respect to the Lenya plugin 
before now. However, we have all been busy with other things. So in 
order to facilitate Anil, we should change this to Daisy.

Ross

Re: Repository browser: Daisy or Lenya ?

[Anil Ramnanan <li...@peppersauce.org>]

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.

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.

The Repository Interface provides the view with the list of the the
documents available. The interface will be built so that it you can plug
in a number of different repositories. This way the Repository View
would be independent of the repository being used.

Daisy was suggested because there is a working Daisy plugin that allows
you to retrieve documents from a Daisy repository.


Anil

Re: Repository browser: Daisy or Lenya ?

[Tim Williams <wi...@gmail.com>]

On 8/8/05, Ross Gardler <rg...@apache.org> wrote:
> Anil Ramnanan wrote:
> > Since I have to develop a repository browser I believe that my choices
> > are Daisy or Lenya. Which of these do you think I should be using ? As
> > Ross said, the Daisy plugin is fairly complete so I am currently leaning
> > in that direction.
> 
> Daisy.
> 
> As you say the plugin is complete whereas we are still awaiting the
> Lenya folk to install a publication for us to play with on their Zone.
> 
> I can provide access to a daisy instance for you to experiment with, or
> you can install it yourself. The later is recommended as it will mean
> you do not need to be online to work. However, this is not the place to
> discuss the installation of Daisy. I'm subscribed to the Daisy dev list,
> so I'll support you there.
> 
> All discussion about Forrest related integration should, of course,
> happen here.
> 
> When building this part of the Eclipse tool it is very important to bear
> in mind that we need to make it generic so that we can quickly "plug in"
> a Lenya repository, or any other such repository. With any luck, by the
> time you have finished the Daisy part we will be ready to go with a
> Lenya repo as well.

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

"Repository Browser
------------------
This will allow you to browse a remote repository and include the
documents into a Forrest site. This browser will focus only on Apache
Lenya at this point since this is the Content Management System most
likely to become part of a proposed Apache wide documentation system.
However, the framework will be flexible so that it can support other
browsers e.g. for Webdav, svn, Apache Slide etc"

Re: Repository browser: Daisy or Lenya ?

[Ross Gardler <rg...@apache.org>]

Anil Ramnanan wrote:
> Since I have to develop a repository browser I believe that my choices
> are Daisy or Lenya. Which of these do you think I should be using ? As
> Ross said, the Daisy plugin is fairly complete so I am currently leaning
> in that direction.

Daisy.

As you say the plugin is complete whereas we are still awaiting the 
Lenya folk to install a publication for us to play with on their Zone.

I can provide access to a daisy instance for you to experiment with, or 
you can install it yourself. The later is recommended as it will mean 
you do not need to be online to work. However, this is not the place to 
discuss the installation of Daisy. I'm subscribed to the Daisy dev list, 
so I'll support you there.

All discussion about Forrest related integration should, of course, 
happen here.

When building this part of the Eclipse tool it is very important to bear 
in mind that we need to make it generic so that we can quickly "plug in" 
a Lenya repository, or any other such repository. With any luck, by the 
time you have finished the Daisy part we will be ready to go with a 
Lenya repo as well.

Ross