[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
--=_alternative 004963E285256F71_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">I have received a similar email from Andre. I will cull through these and open a number of issues for items large enough that they should have their own email thread/resolution and also source an email of suggested editorial changes to which people can raise objections before they get implemented.</font> <br><font size=2 face="sans-serif"><br> Rich</font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>Michael Freedman <Michael.Freedman@oracle.com></b> </font> <p><font size=1 face="sans-serif">12/20/2004 05:32 PM</font> <td width=59%> <table width=100%> <tr> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td valign=top><font size=1 face="sans-serif">WSRP <wsrp@lists.oasis-open.org></font> <tr> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td valign=top> <tr> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td valign=top><font size=1 face="sans-serif">[wsrp] Questions/comments on wsrp 2.0 changes</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><font size=3>From the notes generated when I did my review today ...<br> </font> <br><font size=2 face="sans-serif">1. </font><font size=3>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?</font> <br><font size=2 face="sans-serif">2. </font><font size=3>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?</font> <br><font size=2 face="sans-serif">3. </font><font size=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.</font> <br><font size=2 face="sans-serif">4. </font><font size=3>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?</font> <br><font size=2 face="sans-serif">5. </font><font size=3>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.</font> <br><font size=2 face="sans-serif">6. </font><font size=3>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.</font> <br><font size=2 face="sans-serif">7. </font><font size=3>Lifetime structure: what is the units for duration? Shouldn't this just be a boolean?</font> <br><font size=2 face="sans-serif">8. </font><font size=3>If a producer policy changes during a lifetime that impacts the lifetime do we get ModifyRegistrationRequired faults?</font> <br><font size=2 face="sans-serif">9. </font><font size=3>Clumsy to have Lifetime returned in a RegistrationContext/PortletContext and merely tell folks you don't need to pass in subsequent calls. </font> <br><font size=2 face="sans-serif">10. </font><font size=3>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."</font> <br><font size=2 face="sans-serif">11. </font><font size=3>Do we want to consider making type optional for those that are described in EventDescription?</font> <br><font size=2 face="sans-serif">12. </font><font size=3>RequiresSecureDistribution in Event is clumsy ala Lifetime in contexts above -- its only needed to post an event not receive one.</font> <br><font size=2 face="sans-serif">13. </font><font size=3>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?</font> <br><font size=2 face="sans-serif">14. </font><font size=3>"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?</font> <br><font size=2 face="sans-serif">15. </font><font size=3>URL syntax for getResource encoding is clumsy -- how about a new urlType? resourceByProtocol? It would take a wsrp-resourceId and a wsrp-requiresRewrite.</font> <br> <br> --=_alternative 004963E285256F71_=--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]