I think it would be good to step back from details of which characters are
usable in URIs and look at the bigger picture. The major question we have
to decide is whether the pseudo-services used by callbacks are to be treated
from the user's perspective
a. exactly like SCA services in every respect
b. exactly like SCA services except for a very small number of differences
c. as a different thing from an SCA service with its own set of rules for
how it is used
By treating these exactly like SCA services, I mean doing the following
things with them:
1. Specifying as a target of a reference wire
2. Specifying a callback interface and binding in addition to a forward
interface and binding
3. Creating a ServiceReference that can be passed to setCallback()
4. Creating a ServiceReference that can be used for normal forward
invocations
5. Mapping to an endpoint URI using the standard algorithm defined in
the SCA assembly spec
6. Enforcing name uniqueness rules with respect to other services
7. Including in the calculation of whether a component only has a single
service so that its default URI need not include the service name
8. Automatically creating an exposed endpoint on a configured host server
There could be other aspects that I have overlooked. Please send your
additions to this list.
As a simple solution I'd like to propose that a callback reference defines
an SCA service with the same name as the reference, and that this service
can be used exactly like an SCA service except for points 1 and 2 above,
which are explicitly precluded by the SCA assembly spec. This callback
service would support all the other points on the list above and any other
properties of SCA services that I may have overlooked in the above list.
The soundbite version is: "Callbacks are full SCA services that can't be
wired and can't themselves have callbacks."
Any thoughts or comments on this, or other suggestions?
Simon
Simon Nash wrote:
See inline.
Simon
Jean-Sebastien Delfino wrote:
(cut)
The # symbol has a special meaning in URIs as it separates a URI from
a fragment id. This form of URI will prevent bindings to use fragment
ids to identify the target operation or to append some context to the
URI for example.
RFC 2396 [1], section 4.1 clearly states this:
"When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch ("#") character, consists of additional
reference information to be interpreted *BY THE USER AGENT* after the
retrieval action has been successfully completed. As such, *IT IS NOT
PART OF A URI*, but is often used in conjunction with a URI."
So I don't think that using '#' is a good idea. It may work with some
bindings, will break others.
[1] http://www.ietf.org/rfc/rfc2396.txt
Thanks for explaining the issues with "#". There were other questions
in my last post concerning the use of "/" as the separator. Since you
didn't comment on these, I'm assuming that I have correctly captured
the scenario that causes you concerns with this.
The reference to RFC2396 is extremely helpful and provides (I think)
the necessary information to come up with a good solution to your
"challenge". From this document, we have a few options for the
separator character.
Option 1: Use semicolon (;). In section 3.3 of RFC 2394 this is defined
as delimiting a parameter or parameters that are part of a path
component. It seems quite appropriate to use a ";callback" suffix in
the last path segment of a URI to represent a "callback" parameter.
Option 2: Use any character that's legal within a path component but
not legal in an NCName (used for SCA service and reference names).
The possible characters are
path segment characters in section 3.3:
":" | "@" | "&" | "=" | "+" | "$" | ","
unreserved characters in section 2.3:
"!" | "~" | "*" | "'" | "(" | ")"
I don't have a strong preference here, but ":" and "@" look good to
me, with "!" as a possible alternative.
With any of these approaches, some kind of "callback" suffix appears
explicitly in the URI, rather than relying on a SCDL naming uniqueness
rule and having a URI that doesn't indicate that it's for a callback.
I think having an explicit "callback" indication in the name is helpful
for users, assuming that we can pick a convenient and robust syntax
for this. I hope that one of the above options will satisfy this
requirement.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
