|
Mike,
I think it might be useful to add to the extensibility issue also adding
new type of data that's transferred as part of the requests. What I mean by that
is how can future versions of the protocol that require additional optional
arguments be layered on top of the existing protocol, without change? What I am
driving it to ensure that we end up with an HTTP/SMTP-like model in which each
time data is transferred across the wire, enough extensibility takes place
(e.g., via a name/value abstraction) so that new functionality (such as caching,
via if-modified-since and etags, etc.) can be added without affecting the
protocol signature. Also a more mechanical issue along the same lines is to
ensure that the protocol provides a way to determine the protocol version number
supported so that both parties can adapt accordingly. This latter issue can
probably be abstracted either dynamically (e.g., along the lines of the
HTTP which provides the protocol version on every request) or statically
(i.e., via description of some sort).
--Eilon
Folks,
Another week, another conference call. Same details as always: 8am PST
877.302.8255/303.928.2609 id: 8814427.
Topics this week are:
a) Protocol Extensibility: To date we have talked about the protocol
as a single unit. A number of discussions occurred during the F2F where
this tripped us up. To avoid this we should define our extensibility
model. Currently, I see three needs that we should address:
1) Should we and how do we represent a layered
functional protocol? I.e. in our F2F discussions we discussed
various usage patterns from simple to complex -- should we layer our protocol
to reflect these differing common usage patterns? Technically, this
seems to ask whether our protocol is represented by a single portType or
multiple ones. Dealing with the later seems to complicate
portal/consumer implementations as they must recognize the different
interfaces [though dealing with 3) will surely mean adding new portTypes
anyway].
2) Should we and how do we represent
WSIA discrete function in our protocol? I.e. in out F2F we discussed
whether or not to include transparent property/state management. At this
time, this is seen as a WSIA discrete function [though may be utilized by WSRP
later]. How should we handle this and similar situations?
3) How do we add new function/arguments in the
future? I.e. what is the impact to the protocol every time we need to
add an argument or a method?
I would like our discussion to focus on two things:
a) how [and who] do we put together a
preliminary proposal.
b) what are current
points of view regarding what we should do.
b) JSR 168 compatibility: The current consensus in the JSR 168 expert
group is that [initial] request parameters are available not only to the
action handler but also the render handler. Actions, in JSR 168 don't
return markup -- hence aren't conveniently implemented using
JSPs/servlets. The expert group wants to allow the existing web
application programming style where action and rendering are handled together
to be supported hence the above proposal. Unfortunately, this seems in
conflict with WSRP which says that actions are the only recipient of client
request parameters. We need to discuss how we can align the two
proposals.
Alejandro can you clarify the following?
Note: Its not clear to me whether the JSR 168 consensus is:
a) all URLs are represented
as actions. However the client request parameters sent to the action
handler are also in turn sent to the getmarkup handler. OR
b) there are two types of
URLs: actions and render URLs -- Action URLs work as described by WSRP --
i.e. client parameters sent to the action handler but not the getmarkup
handler. A Render URL is functionally the same as an action URL in
that it represents a user data submission (action), however the call is sent
to the getMarkup handler directly bypassing any action handling.
-Mike-
|