Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (hermes.apache.org: domain of williamstw@gmail.com
 designates 64.233.184.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Qda5ljEm5lVX1vyw5YCn5/Tcfvg1eskAEcvEs0lc6A1CCTQ9a9mxNeXGDZF+OLBhQXCAfyg9qPgZ2AlEmO4rKGqbPAO6rB42X+bNZj3E5gh14/k18crs68iK3pluLG2MquaUoTnk9nSr93HYTUjSE0ZTJLZW7j9h+GP4jKQy16c=
Message-ID: <4998884405060520052985dfa1@mail.gmail.com>
Date: Sun, 5 Jun 2005 23:05:01 -0400
From: Tim Williams <williamstw@gmail.com>
Reply-To: Tim Williams <williamstw@gmail.com>
To: dev@forrest.apache.org
Subject: Re: Locationmap now works for repositories
In-Reply-To: <42A363C2.6040603@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <42A242FE.7010706@apache.org>
	 <4998884405060418582e9eea82@mail.gmail.com>
	 <49988844050605081518de2276@mail.gmail.com>
	 <42A32C7A.8080408@apache.org>
	 <49988844050605114542b6bee7@mail.gmail.com>
	 <42A363C2.6040603@apache.org>

On 6/5/05, Ross Gardler <rgardler@apache.org> wrote:
> Tim Williams wrote:
> > On 6/5/05, Ross Gardler <rgardler@apache.org> wrote:
> >
> >>Tim Williams wrote:
> >>
> >>>After reading, studying *.xmap, and re-reading, I think I'm
> >>>understanding this a bit better.  My question is should the
> >>>locationmap match be moved earlier in the pipeline?  I got the
> >>>behaviour I would have expected by moving it immediately before all of
> >>>the i18n matches for regular source content.
> >>
> >>No. If it were moved to before the i18n match for *.xml files it would
> >>prevent that code from working since the first match in which the
> >>generator is executed is the *only* match that will run.
> >>
> >>Is there a reason why you want to move it earlier?
> >
> >
> > Because a match in xdocs takes precedence over locationmap right now.
>=20
> Yes, this is by design. The assumption is that it is more efficient to
> use a local file than a remote one and so the local file takes
> precedence if it is present. Besides, if we don't give priority to local
> files it will break backward compatability, which we cannot do.

Right, sounds good.  I guess i jumped the gun a bit in thinking it a
bug -- I'd spent a couple hours figuring it out and got overly pleased
with myself i guess:(

> In the final version of the Locationmap system it is likely that *all*
> files will be served via the locationmap which will have a default of
> serving from the local filesystem. However, I'm not sure how to do this
> without breaking the i18N stuff, at least not yet.
>=20
> Note that the locationmap is not actually scheduled until 0.9. It is
> likely that it will first be added as an alpha feature into 0.8-dev once
> 0.7 is released. This will have to go to a community vote though.
> ...
>=20
> > of course site.xml and tabs.xml which are handled differently than
> > other content in xdocs.
>=20
> They are, but they need not be. This is something that needs to be
> addressed. We should be able to get site.xml and tabs.xml from the
> locationmap source too.

I've got both of these working with locationmap now, let me know if
that's preferable. This makes me wonder how "default" locationmaps
will be set up.  Is there a concept of fallback locationmaps sorta
like sitemaps do (e.g., allow project overrides to forrest
pre-defined)?  I guess the question is: have you a grander design yet
for how these things will actually work when it comes to *all*
resources?  It seems like this idea of overriding the forrest
locationmap settings with the project locationmap settings seems
necessary?

> > Also, are you looking into expanding it for resource (graphics
> > specifically) content too?
>=20
> Yes. My goal is to be able to use the locationmap for everything.
> However, this is a pretty big job and could introduce many unexpected
> bugs so would need lots of testing. As you get more comfortable with
> sitemaps and the like, perhaps you can help (hint resources are handled
> by the resources.xmap file).

Clearly there's a lot left to learn but I'm no longer as intimidated
with the *xmaps -- frightening as it may be, they're actually
beginning to make sense now.   Having looked at resources.xmap though,
I agree, it is going to be a big job.  Before looking more at it
though, I'd like to get your vision of how it should work.  Seems to
me there needs to be some sort of forrest:locationmap and
project:locationmap concepts in place first?  In other words as the
locationmap concept is carried over to forrest assets as well as
project assets, should each not have a overridable locationmap?

--tim