RE: [wsrp-interfaces] RE: [wsrp-markup] [wsrp][markup] Aug 14 Con fCall Minutes

Hello,

 

As a 
customer, why would I support a standard that 

  
-----Original Message-----
From: Tamari, Yossi 
  [mailto:]
Sent: Thursday, August 15, 2002 8:52 
  AM
To: WSRP-Markup
Cc: 
  
Subject: [wsrp-interfaces] RE: 
  [wsrp-markup] [wsrp][markup] Aug 14 Conf Call Minutes

  
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.

  
    
-----Original Message-----
From: Chris Braun 
    [mailto:]
Sent: Wednesday, August 14, 2002 
    11:34 PM
To: WSRP-Markup
Subject: [wsrp-markup] 
    [wsrp][markup] Aug 14 Conf Call Minutes

    

    

    
Here are the minutes for this weeks conference 
    call.

    
 

    
Attendees:

    
Chris Braun

    
Michael Freedman

    
Alejandro Abdelnur

    
Carsten Leue

    
Eric Van Lydegraf

    
Andre 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".