Yossi,
Your suggestion is my recollection of the discussion.
The simple (non-attachment) form is required of both producers and consumers
as this is the only form that guarantees interoperability. Rather
then merely making attachments optional however, we discussed having the
spec strongly encourage consumers and producers to support one or both
attachment mechanisms (whatever is available to them) for efficiency and
scalability reasons. In most environments this should be little to
no burden as these factors should map into the same impelmentation.
-Mike-
"Tamari, Yossi" wrote:
Regarding
attachments (SOAP vs. DIME):If
we define three binding factors: SOAP attachments, DIME, and none, and
we define that a producer may choose which ones it supports, and we define
that a consumer does not have to support all three, then why do we require
the consumer to support either DIME or SOAP? We are already saying that
some compliant producers will not be able to work with some compliant consumers,
so what's the point?I
suggest we only require every consumer and producer to support the non-attachment
binding, and make the others optional optimizations.
Yossi.
Here are the minutes for this weeks conference
call. Attendees:Chris
BraunMichael FreedmanAlejandro
AbdelnurCarsten LeueEric
Van LydegrafAndre Kramer Discussion: 1.
Resource URLs
a. Proxy Resource URL
i. Versus Portlet Entity Resources JSR
168 does not have the notion of embedding large binary content within the
markup. JSR 168 only addresses portlets rendering markup or redirecting
to a web resource. Does it make sense for a local portlet to be accessing
the containers response output stream. This does seem contradictory
to the portlet model. This discussion will be continued in the next
JSR 168 conf call as well as the FTF, which is in two weeks. We will
try to incorporate a model for WSRP based on the information that we learn
from the JSR 168 conversations. The key question that has to be answered
is: Do we support the notion of embedding binary data within the
markup of a portlet's markupResponse or would it make more sense to create
a new interface, getResource, for sending binary attachments? TODO:
Alejandro will bring this up as a point of discussion for JSR 168.
ii. Multiple Resource Locations (Proxy URLs) It
was discussed that it may be worthwhile to specify a mechanism from portlets
to be able to use relative references. In a complex producer container,
such as a JSR 168 container, the resource URL is constructed by the container.
This makes the actual URL transparent to the developer. For simple
producers the URLs would have to be fully qualified. Thus, all Proxy
URLs must be fully qualified. weather this is handled by the producer
or the actual entity is out of the scope of WSRP.
b. Portlet Resource URL
i. Do we need another URL type to distinguish between proxy and portlet
entity recourses. Such as wsia:urlType=resource and wsia:urlType=proxyresource Tabled
until next week. May be dependent on how/if binary attachments will
be handled within markup.
ii. Is there a new method signature for the interface, such as getResource()
? Or is this embedded in the getMarkup call? Tabled.
Continue discussion after JSR 168 has a chance to discuss this. 2.
Attachments
a. Soap Vs. Dime
- Soap Dependency
- Effect on WSDL Binding info
- Implementation Specific? SOAP
has issues with carrying large data blocks within the body of a soap message. We
will allow both SOAP-Attachments and DIME. The idea is that we provide
3 WSDL binding schemas: A simple binding schema which does not include
support for attachments; A binding schema which defines SOAP attachments;
A schema which defines DIME attachments. Since DIME requires interface
additions we can add these to the main WSDL interface as optional. We
won't make the requirement that the consumer supports both attachment types.
For example .NET consumers will not support SOAP attachments and a JAX-RPC
container may not support DIME. We will require that the consumer
support one of the WSDL bindings with support for attachments. We
will also require that the consumer must support the simple WSDL binding. TODO:
Alejandro: Follow up with JAX-RPC to understand possible support
for DIME.
Carsten: Prototype (POC) using optional DIME tags within a non-DIME consumer.
Carsten and Andre: Write-up describe consumer relationship with attachment
binding:
Dynamically created proxies and Pre-created proxies
b. Where is the attachment embedded for both a response and a request
(i.e. interactionContext, interactionResponse, markupContext, markupResponse)? The
current thought is that we embed the request attachment within the interactionContext
and the response attachment within the markupResponse. We should
investigate how this would map to the JSR 168 local portlet world. -
Window States
Can portlet entities render action links which change window state? Portlet
entities should be able to render markup links that will enable user to
change window state and portlet mode. To enable this we need to define
well known property names and values. For example wsia:mode=edit|help|configure|view
and wsia:windowState=normal|minimized|maximized. This will be added
to the producer and consumer URL rewrite semantics. We
also need to define an extensibility mechanism so that custom modes (or
possibly window states) can be introduced by portlet producers. The
performInteraction interface should be enhanced to allow entities to programmatically
set window states and portlet modes. Registration
MetaData may need to include a semantic for providing supported modes and
window states as well as custom mode information. We may need to
formalize a custom modes/window state extension mechanism. TODO: Interfaces
Group: Add properties to performInteraction for windowState and Mode
support Postponed
Topics- URL encoding (Revisit)-
Button and Label consistency across portlets
How can configuration interfaces maintain a consistent look and verbiage
across entities. For example when saving customize information should
buttons read "apply" or "save".
|