Return-Path: 
 <dev-return-16544-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 59869 invoked from network); 2 Jun 2005 20:30:34 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 2 Jun 2005 20:30:34 -0000
Received: (qmail 71052 invoked by uid 500); 2 Jun 2005 20:30:33 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 70995 invoked by uid 500); 2 Jun 2005 20:30:33 -0000
Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@forrest.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@forrest.apache.org>
List-Post: <mailto:dev@forrest.apache.org>
Reply-To: dev@forrest.apache.org
List-Id: <dev.forrest.apache.org>
Delivered-To: mailing list dev@forrest.apache.org
Received: (qmail 70977 invoked by uid 99); 2 Jun 2005 20:30:33 -0000
X-ASF-Spam-Status: No, hits=0.1 required=10.0
	tests=NORMAL_HTTP_TO_IP
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from ns3.wkwyw.net (HELO ns3.wkwyw.net) (217.199.181.91)
  by apache.org (qpsmtpd/0.28) with SMTP; Thu, 02 Jun 2005 13:30:31 -0700
Received: (qmail 25623 invoked from network); 2 Jun 2005 20:30:23 -0000
Received: from 82-69-78-226.dsl.in-addr.zen.co.uk (HELO ?192.168.0.4?)
 (82.69.78.226)
  by ns3.wkwyw.net with SMTP; 2 Jun 2005 20:30:23 -0000
Message-ID: <429F6C51.20300@apache.org>
Date: Thu, 02 Jun 2005 21:30:09 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Slide Integration
References: <4998884405051804394ad8a1d7@mail.gmail.com>
	 <428B340D.6060209@apache.org>	 <4998884405060111091035e419@mail.gmail.com>
	 <429ED6FF.1000207@apache.org> <4998884405060212303912a084@mail.gmail.com>
In-Reply-To: <4998884405060212303912a084@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Tim Williams wrote:
> On 6/2/05, Ross Gardler <rgardler@apache.org> wrote:
> 
>>Tim Williams wrote:
>>
>>>Sent to dev as suggested.
>>>
>>>On 5/18/05, Ross Gardler <rgardler@apache.org> wrote:
>>>
>>>
>>>>Tim Williams wrote:
>>>>
>>>>
>>>>>Has anyone already documented how to use Slide as a backend to
>>>>>Forrest?  If not maybe some high-level pointers of where to start?
>>>>
>>>>Nobody has documented this, or to my knowledge tried it.
>>>>
>>>>You'd probably find more help on the dev list, where we will be glad to
>>>>help you. Please send your question there with a description of a use
>>>>case describing exactly how you would like the integration to work (may
>>>>seem like an obvious thing, but it gives us a common language to
>>>>communicate ides with).
>>>>
>>>>Ross
>>>
>>>
>>>I guess I could give long and short term goals/use-cases.
>>>
>>>In the short term,
>>>I'd like to simply be able to point  "project.xdocs-dir" in
>>>forrest.properties to a slide repository like:
>>>project.xdocs-dir=http://127.0.0.1:8080/slide/xdocs
>>
>>OK, I'm experimenting with this kind of integration right now. Not with
>>Slide but with Daisy. Take a look at the Daisy plugin in whiteboard.
>>
>>Currently, the location of the repository is encoded in request
>>parameters. This is *not* good.
>>
>>The problem with this approach is that a) it is difficult to write the
>>hrefs b) it is impossible to build a static site because the request
>>parameter '?' is converted to an '_' in the filename ('?' is not legal
>>in a filename)
>>
>>The solution to this problem is the locationmap work. This allows you to
>>map request patterns to a location. For example:
>>
>><match pattern="docs/**">
>>   <location href="http://127.0.0.1:8080/slide/xdocs/{1}"/>
>></match>
> 
> 
> So does input.xmap go from being a sitemap to a locationmap or does it
> just add a few elements to the sitemap doctype?  I guess I'm still not
> understanding where the locationmap matchers actually go in terms of
> the plugin.

The locationmap is not a sitemap in the same sense as a cocoon sitemap. 
It uses the same syntax because it reuses much of the code.

>>For more information see http://issues.cocoondev.org/browse/FOR-200

 From that URL you will find a link to the original discussion about 
locationmaps that includes a description of the original commit and an 
example of how to use it - see 
http://marc.theaimsgroup.com/?t=106638785400004

Things have not progressed any from that original contribution except...

>>I'm currently experimenting with the locationmap code, I have it working
>>"to an extent". But have not yet managed to get it to work at the
>>generation stage (through lack of time rather than a problem with the
>>code, I think). I will attach a patch against the current SVN tree to
>>the above issue that will enable the location map if you would like to
>>experiment with it. It would be great to have someone working with me on
>>this, you with Slide, me with Daisy (and Thorsten is looking at Lenya
>>integration).
> 
> 
> I'd like to see the location map patch.  That sounds like the way to
> go.

I should find the time tomorrow to put the patch together with a simplyu 
little demo.

>  What does "generation stage" mean though, does what I'm talking
> about fall into that particular stage?

I'll try and explain what I mean:

The original description of functionality (at 
http://marc.theaimsgroup.com/?t=106638785400004 ) only described link 
translation. Meaning that a page with an lm: psuedo protocol href was 
converted by the locationmap input-module to be a link to a specified 
location. This is similar to the site: or ext: psuedo protocols in 
Forrest. This works fine in the transformation stage. In other words, if 
you have content with:

<a href="lm:myslidedocs/file.html">...</a>

and a locationmap of:

<match pattern="myslidedocs/**">
   <locator src="http://127.0.0.1:8080/slide/xdocs/{1}"/>
</match>

the resulting content will be translated to:

<a href="http://127.0.0.1:8080/slide/xdocs/file.html"/>

This isn't quite what I want (and I think what you want). The problem is 
that the link is translated in the source, so the URL the client sees is 
the trnalsated URL. This prevents Forrest from processing the request as 
the client requests directly from the repository source.

I'd prefer to have:

<a href="myslidesdocs/file.html">...</a>

and a locationmap with:

<match patern="myslidedocs/**.xml">..</a>
   <locator src="http://127.0.0.1:8080/slide/xdocs/{1}.xml"/>
</match>

(NOTE the .xml extension as opposed to .html)

In this case Forrest will request "myslidesdoc/file.html", this will 
result in an internal request for "myslidesdoc/file.xml" through 
existing Forrest processing. The locationmap then maps this request to 
"http://127.0.0.1:8080/slide/xdocs/file.xml" which then gets processed 
by forrest and returned to the client as "myslidesdocs/file.html".

In other words, the href "myslidesdocs/file.html" remains that same URL 
in the client but actually is generated internally to Forrest from 
"http://127.0.0.1:8080/slide/xdocs/{1}.xml"

>>>In the long term,
>>>I'd like to do the same as above, but have some sort of workflow state
>>>metadata understood by both the authoring environment (Epic/Spy) and
>>>publishing engine (Forrest).  I'm thinking some fairly simple states
>>>like: New, Author, Edit, Publish and then Forrest would be able to
>>>inspect that metadata and only publish those documents with the
>>>"Publish" state.
>>
>>With the Daisy integration (and I assume Lenya) this will be possible.
>>Those systems provide full workflow control. I would be concerned about
>>duplicating their effort here in Forrest. What would be good though is
>>for us all to agree on a standard repository plugin that could be
>>configured to work with various different repository tools.
> 
> 
> No, I wasn't suggesting that part (workflow) actually be a part of
> Forrest, I just described that to give an idea of where I'd like to
> be.

OK, in that case we have the same vision.

> Epic/Spy - Authoring
> Lenya - Workflow/Site Management

I'm not sure if it is possible to separate the workflow/site management 
functionality from Lenya in this way.

Thorsten is a Lenya committer as well as  aForrest committer. He will be 
able to discuss the Lenya aspects with you. I decided not to use Lenya 
because I could find no simple way of separating the repository from the 
editing system.

> Forrest  - Publishing
> Slide - Content Repository
> 
> I haven't see Daisy yet but I'll take a look at that too.

The big advantage of Daisy is its clear separation of editing from 
repository. The disadvantage is that it is not as mature as some other 
editrs/workflow systems. Recently they have started to put effort into 
expanding the develope community. I hope this will help make the 
framework develop, in my opinion it is an excellent framework.

Whatever path we take individually (Lenya, Daisy and Slide integration) 
we should endeavour to make a single plugin for Forrest that can work 
with each of the various repositories. I'm not sure how realistic this 
is, but lets see what we can do. The locationmap, I think, will be the 
connecting point.

Ross