Sounds good ;)
I was going to suggest a rewrite to match the terminology used in the RFC
I agree on everything so far:
- The #fragment shouldn't be routable as it is only of relevance for
the agent receiving the document ( this is one of those rules nobody
ever followed ).
- Yes, resources are identified by FULL URIs ( well, after
cannonicalization when possible )
hmm, sorry I have to run now. But I will happily help you on the
rewrite, please let me know when you have something checked into
subversion so I can look at it and provide any feedback.
Thanks!
Aldo
On 12/6/06, Chris Grindstaff <[EMAIL PROTECTED]> wrote:
Tuesday, December 5, 2006, 6:55:18 PM, you wrote:
JL> Hi all,
JL> The recent initiative on URI templates standardization [1], the potential
JL> confusion between Java Regex and the support for URI templates added in beta
JL> 20, a close reading of the URI RFC [2] and the recent comments from Chris
JL> Grindstaff and Yuri de Wit led me to fully rething the URI routing in the
JL> framework.
JL> Here are some conclusions that I have reached:
JL> - resources are identified by a URI, not just the hierarchical path of a
JL> URI
JL> - valid URIs such as URNs should be easily routable, like HTTP URLs
JL> - the query part of URIs should be easily routable, like the path part
JL> - the fragment part of URIs shouldn't be routable, as defined by URI RFC,
JL> section 6.1 [3]
JL> - several query part formats are possible and should be supported
JL> - the common one ("p1=v1&p1=v2&p2=v3") should have additional support (via
JL> Reference.getQueryAsForm() method for example)
JL> I'm planning to refactor this part of the framework for 1.0 RC1. I will add
JL> a Route class (subclass of Scorer containing a list of variable description)
JL> and a Variable class describing the type of template variable (regex to
JL> match, etc).
JL> Any thought?
Jerome,
So far sounds good. I look forward to seeing the new code.
-Chris
--
Chris Grindstaff | http://gstaff.org
--
::::: Aldo Bucchi :::::
mobile (56) 8 429 8300
