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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: Questions/comments on wsrp 2.0 changes


 From the notes generated when I did my review today ...
 

   1. Impact of adding getResource to markup interface.  Are producers
      required to support this?  Only if they encode URLs to call it?
       Shouldn't we have meta data
      inRegistration/GetServiceDescription/PortletDescription that
      allows Producers to adapt to consumer that don't support?  I.e.
      make it easy for 1.0 consumers to run 2.0?
   2. HandleEvent:  should it take InteractionParams?  What is the
      reason for this vs. this is only sent to
      performBlockingInteraction?  Looks like all its used for is to
      pass the portletStateChange flag.  Should we put this in something
      else like EventParams?
   3. Lifetime:  should we allow a consumer to request a lifetime for
      either registration or portlet?  A little clumsy to have to call
      back and do a set.
   4. PortletLifetime operations.  Should they take a UserContext to be
      consistent?  Or do we have the whole UserContext discussion and
      exclude from existing APIs because not used to carry "application
      role" information?
   5. Why do we allow publishedEvents to be wildcarded?  Is the idea
      that I can generate any/all events from a known set when that set
      comes from someone else?  Do we really want this as it adds extra
      for for consumer for seemingly little gain.
   6. Now that we are adding "capabilities" to PortletDescription do we
      want to allow "required" PublicParameters?  I suggest not -- hence
      need to update the document indicating that capabilities for
      PublicParameters must be mutable and can't be required.
   7. Lifetime structure:  what is the units for duration?  Shouldn't
      this just be a boolean?
   8. If a producer policy changes during a lifetime that impacts the
      lifetime do we get ModifyRegistrationRequired faults?
   9. Clumsy to have Lifetime returned in a
      RegistrationContext/PortletContext and merely tell folks you don't
      need to pass in subsequent calls.  
  10. Cache control wording changes -- almost there.  how about: "If the
      cacheControl field is not supplied, the Portlet is indicating it
      does not consider the markup cacheable. This is without prejudice
      to consumer specific caching policies."
  11. Do we want to consider making type optional for those that are
      described in EventDescription?
  12. RequiresSecureDistribution in Event is clumsy ala Lifetime in
      contexts above -- its only needed to post an event not receive one.
  13. I thought we decided that HandleEvents couldn't cause a redirect?
       Or did we just decide its up to the consumer to honor whichever
      redirect they receive?
  14. "While the Consumer MAY invoke handleEvent() multiple times for
      any one portlet while preparing to gather markup, it MUST NOT
      invoke handleEvent() an additional time while the portlet is
      already processing an event for the same End-User."  This implies
      the consumer can't implicitly timeout an event call without
      dropping subseqent events from being distributed.  Is this what we
      want?
  15. URL syntax for getResource encoding is clumsy -- how about a new
      urlType?  resourceByProtocol?  It would take a wsrp-resourceId and
      a wsrp-requiresRewrite.




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