On 8/27/05, Doug Chestnut <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I've suggested using the "Area" for the XMAP. It would make adding a
> > "webdav" (or any other) Sitemap/XMAP/Usecase/Publet/Module [choose
> > your favorite name] easy. So the URLs would be:
> > /MY-PUB/webdav/somedoco.html
> > /MY-PUB/live/somedoco.html
> > /MY-PUB/authoring/somedoco.html
> > /MY-PUB/myUsecase/somedoco.html
> > /MY-PUB/myPublet/somedoco.html
> >
> > {pub}/authoring.xmap should just pass control to {pub}/live.xmap so
> > they can share code.
>
> Or, take this out of the path alltogether:
> webdav.mydomain.com/pubid/index.html
> live.mydomain.com/pubid/index.html
> authoring.mydomain.com/pubid/index.html
>
> This is the type of thing that we usually have to hack together with
> mod_rewrite for the live and authoring areas anyway.
>http://mail-archives.apache.org/mod_mbox/lenya-dev/200507.mbox/[EMAIL
>PROTECTED]
Lenya should work solely with the URL path, never server names.
It is easy to write rules for a virtual server to rewrite the URL and
proxy to the Lenya application. It would be very difficult for Lenya
to force the server names. Most want "www", not "live". Some run
Lenya under Tomcat. Requests to the "www" virtual server may be
passed to http://lenyaserver/pub/live/{requestedDoc} or
http://tomcatserver/lenya/pub/live/{requestedDoc}. Lenya core should
not force the server names, or depend on them for functionality.
The other objection is the requirement for multiple server names. To
have "webdav.mydomain.com", "live.mydomain.com", and
"authoring.mydomain.com" requires playing with DNS. That can be
difficult in large organizations. It would also cause problems for
developers and software reviewers who currently use
http://127.0.0.1:8888 to access Lenya. Anything requiring more
configuration before Lenya can be reviewed should be discouraged, and
every alternative considered.
---
In the referenced post, Torsten Schlabach asks for an easy method for
closing the "authoring" area for production servers. Replacing the
"area" with the "XMAP" would do that. To keep the current
maintainability, "authoring.xmap" should pass control to "live.xmap".
For the production server, just replace "authoring.xmap" with one that
returns "sorry.html". An "authoring.xmap" could be written to check
the name of the current server against a configurable list to decide
whether to pass control to live.xmap or return the error page.
---
I think this change would require:
1. Changing/adding some files:
publication-sitemap.xmap -> live.xmap (or have one redirect to the other.)
authoring.xmap (new, just redirects to live.xmap)
2. Minor changes to the global XMAPs:
Check for "{pub}/{area}.xmap", then "{pub}/usecase-{area}.xmap", then
the same for global files. This is so we do not need to remove
"usecase-" from many filenames, but that naming convention would be
deprecated. Use "lenya.usecase=" querystring would also be
deprecated, but should have priority over the "area" for backwards
compatibility.
3. May require changing the PageEnvelope code.
Are there any other considerations?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
