cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerard van Enk" <>
Subject RE: Variations on a theme by Cocoon
Date Wed, 16 Feb 2000 07:33:46 GMT
> Niclas Hedhman wrote:
> >
> > Pierpaolo Fumagalli wrote:
> >
> > > Gerard van Enk wrote:
> > > >
> > > > Is this what we want???? See <>
> > >
> > > Nope...
> > >
> >
> > That was an absolute :o)
> >
> > I am not sure what Gerard is hinting, or what Pier is so negative about.
> I just said that it was not what we wanted... I don't see how a document
> on "why links should be preserved" fit in the scope of our discussion:
> we're talking about how to produce generators...
You were talking about wrong link-mapping, link.class instead of the wanted

But you're right, it doesn't fit in this discussion......

> > But my understanding from the articles, is URI persistence over time,
> > long time. There are a few alerters in the article, such as use of
> > extensions, topic mapping and exposure of technologies used.
> And the Cocoon sitemap perfectly adresses this problem... Since all the
> requests are made against a virtual uri space, whatever you do with your
> sources, you can preserve the names in the URIs...
> If today your news page is an XML edited by hand, you have
> <process uri="news.html" source="news.xml">
> ...
> if tomorrow you develop a nice XSP that gets the news out of a database
> you'll just have to rewrite the rule:
> <process uri="news.html" source="news.xsp">
> ...
> And requests to "news.html" will be preserved... Same uri for the
> client.

Wow, I didn't thought of it this way.....that's cool, the extension-problem
is solved 8-)

> > These are valid concerns in the Cocoon context.  And while we develop
> > Cocoon we must take into considerations that people will be able to use
> > Cocoon in a URI persistent manner. This is largely an educational issue,
> > more than a technical, except if Cocoon depends on extensions to
> > function. We need to clearify in Cocoon what would be PUBLIC URIs and
> > internal URIs. The former should be allowed to take the form described
> > in the document above and elsewhere, whereas the internal ones are
> > non-critical.
> I believe this issue IS SOLVED with the sitemap... The sitemap allows
> you to preserve the target URI space (the URIs requested by the client)
> in a completely transparent  manner.

In a few hundred years we can still use the same extension and just map it
in the sitemap to another extension.......this makes my mail with the
subject "extensions in public URIs" obsolete, so please ignore this 8-)

> Now, I don't think I'm being negative, I just say that we need to focus
> on what should be done, and not what have been already discussed and
> solved...

You're right!


View raw message