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

No you 
not overreacting as we must have plug and play. The talk concluded that we would 
have 

a 
simple interoperability binding (as Yossi suggests) but that we would strongly 
recommend 

use of 
an attachment mechanism for performance . 
A todo is determining how easy it will be

for 
developers to use WSDL tool chains for attachments, without having to massage 
the

wsdl 
or resort to (a library of hand coded stubs) and how the best binding is to be 
selected.

 

    -- Andre

  
-----Original Message-----
From: Rudnicki Joseph G CONT NSSC 
  [mailto:]
Sent: 15 August 2002 
  14:48
To: 'Tamari, Yossi'
Cc: 
  ; 'Jacobs, Michael B'
Subject: 
  RE: [wsrp-interfaces] RE: [wsrp-markup] [wsrp][markup] Aug 14 Con f Call 
  Minutes

  

  
Hello,

  
 

  
Sorry for the first partial reply.

  
 

  
As a 
  customer, I have been concerned 
  with the statement: 

  
 

  
"some compliant 
  producers will not be able to work with some compliant 
  consumers."

  
 

  
Now, it appears that it will become even 
  more complex to determine if a given producer-consumer pairs will work 
  together. If we continue using this 
  philosophy, WSRP becomes less 
  useful relative to our requirements. Am I 
  overreacting?

  
 

  
Take 
  care.

  
 

  
Joe 
  Rudnicki

  
Department of Navy Chief 
  Information Officer Representative to 
  WSRP

  
 

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