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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-markup message

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


Subject: RE: [wsrp-markup] [wsrp][markup] Aug 7 Conf Call Minutes




Comments:

[2] I agree to your comments in general and especially that streaming would
not work. But from my understanding [1-3] would all be options in WSRP and
for streaming resources the producer would have to decide between [1] and
[3]. I think that [2] is a valid option for compability reasons with the
JSR168 that allows portlets to return documents instead of markup.

[3] I also prefer this approach

Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



|---------+---------------------------->
|         |           Eric VanLydegraf |
|         |           <ericv@kinzan.com|
|         |           >                |
|         |                            |
|         |           08/09/2002 01:59 |
|         |           AM               |
|---------+---------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |       To:       "'Chris Braun'" <cbraun@silverstream.com>, WSRP-Markup <wsrp-markup@lists.oasis-open.org>                     |
  |       cc:                                                                                                                     |
  |       Subject:  RE: [wsrp-markup] [wsrp][markup] Aug 7 Conf Call Minutes                                                      |
  |                                                                                                                               |
  |                                                                                                                               |
  >-------------------------------------------------------------------------------------------------------------------------------|



Comments at 3. Resource URLs
      -----Original Message-----
      From: Chris Braun [mailto:cbraun@silverstream.com]
      Sent: Thursday, August 08, 2002 10:01 AM
      To: WSRP-Markup
      Subject: [wsrp-markup] [wsrp][markup] Aug 7 Conf Call Minutes

      Minutes from August 7 WSRP Markup Call

      1. URL Rewriting
          a.  Consumer URL Rewriting
              - Complexity differences between Resource and Action URLs

      [discussion]
      It was discussed that requiring a consumer to rewrite (Namespacing
      and URLs) proxied resources would put a large burden on the consumer.
      For the first rev of the spec we will require that the consumer
      rewrite portlet entity markup only.  It will be the producers
      responsibility to handle static resources.  One solution is to allow
      for the getmarkup call to return resources other than markup.
      Consumer URL rewriting can then occur on the content provided by
      getMarkup.  We should also add a property to the getMarkup response
      to indicate weather or not Consumer URL rewriting should be done on
      the returned resource.

              - Marker Syntax
          b.  URL Encoding/Decoding (
      http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars)

      [discussion]
      For all WSRP URLs we will require that the URLs be encoded in UTF-8
      and then escaped.  We will provide a reference to the above URL in
      the spec.

      2.  Markup Encoding
          a.  Consumer provides list of accepted encoding charsets.  Rather
      than requiring UTF-8, this would be more flexible.  Where a consumer
      may choose to accept UTF-8 as well as a client specific encoding.

      [discussion]
      The Consumer will provide a preferred a preferred charset on the
      request to the producer entity.  The producer will then have to
      encode the markup with that charset.  The Consumer may also perform
      charset conversion.  If the consumer provides this feature a property
      will be set in the registration parameters set to true.  False will
      be the default.  If the Consumer provides charset conversion then a
      portlet is free to generate markup in any standard charset encoding.
      This will need to be added to the Meta-Data area of the spec as well
      as the markup section.

      3. Resource URLs

      [discussion]
      Three types of Resource URLs:
      1.  Direct URL
          A simple URL to any resource on the web, neither proxied or
      served by the portlet entity.
      2.  Portlet Entity URL (link to portlet which serves a resource via
      getMarkup)
          A URL pointing back to the portlet entity which tells the
      consumer to execute getMarkup to retrieve a specific resource
      3.  Proxied URL
          A URL to a resource somewhere on the web (perhaps on the portlet
      entities host) which must be proxied by the consumer so that clients
      retrieve all resources for a particular portlet entity from the
      consumer.
      [Eric VanLydegraf] I would like to confirm my understanding of 2 & 3

      [2] - are we talking specifically WSRP/SOAP only for retrieving
      Resources ?

      Then you have to consider the cost of SOAP marshalling and
      unmarshalling (Unless the attachments issue works out)

      Streaming URL resources wouldn't work

      The Producer has to be willing or able to wrap all resources around
      SOAP - given that many resources will probably
      already be deployed on FTP or HTTP servers in possibly alternate
      locations than the WSRP Producer container might be hard pressed to
      support this.

      On the positive side it certainly keeps everything in the WSRP
      protocol which has a real nice appeal ;)

      [3] Proxied URL - Consumer makes URL protocol connection on behalf of
      client and returns URL content to client.

      - Browser URL location and url's on the same page are consistent
      ("Consumer URL Branding")

      - cookies and security can be kept at Consumer and used for proxy
      services.

      e.g. Basic Auth, or Form Based Auth doesn't have to be repeated for
      external URL's ( kind of poor mans Single Sign On (SSO)
      so user is only prompted once (assuming Consumer and Producer have
      worked out security credential sharing (e.g. LDAP) or secure token
      passing, or consumer is holding on to a password vault of Producer
      user passwords)

      A 3rd party SSO service can alleviate the multiple logins, but that
      may not be available to Consumer or Producer so Proxy would have to
      be used.

      - Resource is not directly available to client but is directly
      available to Consumer

      Note: one motivation for Consumer brokerage of resource access is
      Auditing for consumer = can track resource downloads or usuage, site
      exit points  (Usage tracking, or producer auditing for contractual
      validation purposes aka proof for lawyers - note a 3rd party source
      is more likely but that would just mean somebody else is doing the
      proxying instead of the consumer )

      [Eric VanLydegraf]
       There was some discussion that Proxied URLs are not required if we
      allow portlets to serve resources themselves.  The idea is that the
      producer container can handle the resources.  This would further
      simplify the consumer container.

      TODO:  We should identify if there are use cases where a proxied URL
      would be required.  Do we need both portlet URLs and proxied URLs?

      4. Attachments
          a. Sending in response (use case)

      [discussion]
      Portlet entities should be able to provide markup and other resources
      via the getMarkup call.

          b. Posting in request (use case)

      [discussion]
      A portlet entity should be able to post large binary content back to
      itself from the consumer.  An example of this is posting multi-part
      form encoded content.

          c. SOAP vs. DIME

      [discussion]
      Soap attachments are bound to SOAP where as WSRP should not be bound
      to a specific protocol.  DIME is supported by .NET while SOAP is
      supported by JAX-RPC.  It seems likely that JAX-RPC will support
      both, down the road.

      TODO: Carsten will investigate the status of these specifications and
      relay the information to the group.

      Postponed topics

      - Window States
          a.  Can portlet entities render action links which change window
      state?




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


Powered by eList eXpress LLC