OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [wsrp-interfaces] [wsrp][interfaces] Agenda 7/11


Okay.  Good point.
   -Mike-

Eilon Reshef wrote:

 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
-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Tuesday, July 09, 2002 6:39 PM
To: interfaces
Subject: [wsrp-interfaces] [wsrp][interfaces] Agenda 7/11
 
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-



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC