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: [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>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Michael Freedman &lt;Michael.Freedman@oracle.com&gt;</b>
<p><font size=1 face="sans-serif">12/20/2004 05:32 PM</font>
<td width=59%>
<table width=100%>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">WSRP &lt;wsrp@lists.oasis-open.org&gt;</font>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<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>
<tr valign=top>
<br><font size=3>From the notes generated when I did my review today ...<br>
<br><font size=2 face="sans-serif">1. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>Impact
of adding getResource to markup interface. &nbsp;Are producers required
to support this? &nbsp;Only if they encode URLs to call it? &nbsp;Shouldn't
we have meta data inRegistration/GetServiceDescription/PortletDescription
that allows Producers to adapt to consumer that don't support? &nbsp;I.e.
make it easy for 1.0 consumers to run 2.0?</font>
<br><font size=2 face="sans-serif">2. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>HandleEvent:
&nbsp;should it take InteractionParams? &nbsp;What is the reason for this
vs. this is only sent to performBlockingInteraction? &nbsp;Looks like all
its used for is to pass the portletStateChange flag. &nbsp;Should we put
this in something else like EventParams?</font>
<br><font size=2 face="sans-serif">3. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>Lifetime:
&nbsp;should we allow a consumer to request a lifetime for either registration
or portlet? &nbsp;A little clumsy to have to call back and do a set.</font>
<br><font size=2 face="sans-serif">4. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>PortletLifetime
operations. &nbsp;Should they take a UserContext to be consistent? &nbsp;Or
do we have the whole UserContext discussion and exclude from existing APIs
because not used to carry &quot;application role&quot; information?</font>
<br><font size=2 face="sans-serif">5. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>Why
do we allow publishedEvents to be wildcarded? &nbsp;Is the idea that I
can generate any/all events from a known set when that set comes from someone
else? &nbsp;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. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>Now
that we are adding &quot;capabilities&quot; to PortletDescription do we
want to allow &quot;required&quot; PublicParameters? &nbsp;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. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>Lifetime
structure: &nbsp;what is the units for duration? &nbsp;Shouldn't this just
be a boolean?</font>
<br><font size=2 face="sans-serif">8. &nbsp; &nbsp; &nbsp; &nbsp;</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. &nbsp; &nbsp; &nbsp; &nbsp;</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. &nbsp;</font>
<br><font size=2 face="sans-serif">10. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>Cache
control wording changes -- almost there. &nbsp;how about: &quot;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.&quot;</font>
<br><font size=2 face="sans-serif">11. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>Do
we want to consider making type optional for those that are described in
<br><font size=2 face="sans-serif">12. &nbsp; &nbsp; &nbsp; &nbsp;</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. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>I
thought we decided that HandleEvents couldn't cause a redirect? &nbsp;Or
did we just decide its up to the consumer to honor whichever redirect they
<br><font size=2 face="sans-serif">14. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>&quot;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.&quot;
&nbsp;This implies the consumer can't implicitly timeout an event call
without dropping subseqent events from being distributed. &nbsp;Is this
what we want?</font>
<br><font size=2 face="sans-serif">15. &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>URL
syntax for getResource encoding is clumsy -- how about a new urlType? &nbsp;resourceByProtocol?
&nbsp;It would take a wsrp-resourceId and a wsrp-requiresRewrite.</font>
--=_alternative 004963E285256F71_=--

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