Rapha�l Luta wrote:
>
> burtonator wrote:
> >
> > Rapha�l Luta wrote:
> > >
> > > burtonator wrote:
> > > >
> > > >
> > > > > Imagine the file is a jsp, cfm, php,... If you don't use the URL, these won't
> > > > > be used correctly.
> > > >
> > > > We need a regular expression entry within JetspeedResources.properties
> > <snip>
> > > That's a hack ! There's no *correct* way to determine if a URM is dynamic or not:
> >
> > Yes. It is. I think it is worth it for the performance advantage. It
> > would be bad to have content stored in the JetspeedDocumentCache which
> > is already on the local webserver and is static. This will mean more
> > work for the HTTP server, DiskCacheDaemon, DiskCache and OS (IP stack).
> >
>
> Don't think so. Once the fetched the file and put it in cache, you're in a
> periodic cache refreshing mode that certainly would stress your HTTP server.
> The main disadvantages I see are storage space related, but then storage
> is cheap...
>
> > I would *much* rather pull static content directly from the FS if it is
> > local.
> >
>
> use file:// URLs to refer to local static files.
Can't use this in a safe manner. Where is the current directory? What
if you move the application around? All these things break file://
URLs.
This is why I introduced the virtual URL mechanism in Jetspeed. If you
specify:
/content/test.html
It will find this for you and give you the actual file :)
<snip>
> This is certainly not true for me. We have more tahn a thousand pages on
> our site, with several applications, none developped by the same team. I
> don't know for sure when I look at a local URL if it is dynamic or not
> without checking.
> If a project leader wants to "publish" his pages to Jetspeed and gives me an
> URL, I want to be able to register it without worrying about dynamic, static
> aliased, implicit URLs...
ug... I don't like this. I realize that it is technically possible but
IMO is a BAD design. I have seen people do this before but it just ends
up confusing people and causing problems.
It is really a good idea for people to use .jsp, .asp, .cgi, .exe, .bin
extensions on their CGIs so that this is obvious to developers/engineers
what is happening. Especially for new recruits or other departments.
> > Implicit document calls like index.jsp will match through regexp. Path
> > info you get for free :)
> >
>
> How do you match something that doesn't appear in the URL ?
What? If it doesn't appear in a URL you can't reference it... what do
you mean?
> How do you know thazt some part of an URL is path_info and thus you should
> not match against it ?
If it is path_info then the application is dynamic anyway so if it
returns true this is good.
> How do you resolve URL->file with [aliased|redirected|mod_rewrited] URLs ?
If the first URL is dynamic it is almost certainly true that the second
URL is dynamic :)
> How do you know that the .html file you're calling doesn't include some SSI ?
In Apache it is usually .shtml.
> Come on, let's not spend time implementing a mechanism that will fail for 70%
> of the requests, nearly every pages are dynamic nowadays...
This is a bug for right now. A way around it is to put another entry in
/etc/HOSTS which is the same IP but is a different hostname. Jetspeed
should think this is remote and then put it in the cache. This is a
temporary workaround.
I would rather wait on this issue. I am not convinced that either
proposed solution is perfect. It might be better to just pass URL
information from PSML into Jetspeed... something like:
<url nocache="true">/content/test.xml</url>
Kevin
--
Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey:
burtonator)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme
excellence consists in breaking the enemy's resistance without fighting.
- Sun Tzu, 300 B.C.
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
