[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interop] Groups - WSRP Interop SC call modified
| Andre Kramer <andre.kramer@eu.citrix.com>
07/18/2003 04:48 AM |
To: "'Richard Jacob'" <richard.jacob@de.ibm.com>, Andre Kramer <andre.kramer@eu.citrix.com> cc: wsrp-interop@lists.oasis-open.org Subject: RE: [wsrp-interop] Groups - WSRP Interop SC call modified |
I don't mind making consumers more robust (the null markup from getMarkup case) but we should not be breaking use cases we support in 1.0 (returning a title from pbia and no markup).
regards,
Andre
-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 18 July 2003 09:33
To: Andre Kramer
Cc: wsrp-interop@lists.oasis-open.org
Subject: RE: [wsrp-interop] Groups - WSRP Interop SC call modified
Hi Andre,
I disagree here, this is yet another usage pattern for
MarkupContext.
I think that MarkupContext should be handled in the same way, no matter
whether it was returned from getMarkup() or performBlockingInteraction().
Furthermore we have added MarkupContext to the UpdateResponse as an
optimization to save the additional getMarkup() call if markup can be
returned from pba() - that's one reason why MarkupContext should be handled
in the same way for both operations.
Why do you want to return a title in pba() and the let the Consumer call
getMarkup() right after this to obtain the markup? Why couldn't in this
case the title be returned in the getMarkup() response?
If you just want to change the title in pba() but remain the markup in
the
portlet fragment this would implicitly mean that the consumer has to cache
the markup always - even if we don't call it caching here? Couldn't for
that purpose the usedCachedMarkup flag be set to true? (Consumer supporting
caching would adher to the pattern you want).
So again even if I stress it, here is my interpretation/usage
pattern of
MarkupContext.
1. if pba() doesn't return MarkupContext in the UpdateResponse, i.e. it
doesn't occur on the wire (btw. it isn't nillable), then the Consumer
subsequently calls getMarkup() to obtain the markup.
2. if MarkupContext is returned within UpdateResponse, then the Consumer
handles it in the same way as if would have returned it from getMarkup()
and doesn't call getMarkup() any more.
3. if markupString and markupBinary is missing, then it is interpreted
as
"there is no content to display in the portlet's fragment", i.e.
the
consumer can choose to display "" for a better end user experience
instead
of throwing faults. In this case also the mimeType is missing in
MarkupContext.
4. if either markupString or markupBinary is there, then it is interpreted
as "display exactly this markup". In this case the mimeType must
be passed
with MarkupContext.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Andre
Kramer |
| | <andre.kramer@eu.|
| | citrix.com>
|
| |
|
| | 07/18/2003
09:21 |
| | AM
|
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsrp-interop@lists.oasis-open.org |
| cc: |
| Subject: RE: [wsrp-interop] Groups - WSRP Interop SC call modified |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Rich, thanks for the clarifications.
However, I still have a problem with 3b. How can performBlockingInteraction
return a new peferredTitle and no markup?
In this case markupContext is not nill or missing and has:
(a)markupContext.peferredTitle = "some new title"
(b)markupContext.mimeType, markupContext.markupString and markupBinary
are
all null.
Should (b) not be interpreted as "set title and call
getMarkup", rather
than skipping getMarkup and displaying an "" to the user (the
latter is
what I understood from the minutes)? I don't want to be forced to use the
early markup optimzation just to set a title.
And, in future CacheControl may be returned without markup
from pbia, so we
should not be defining rules like "if these fields are null then this
means
skip getMarkup" (or checking for (a and b) as a special case) as this
can
not be expressed in wsdl. I would prefer to make (b) mean call getMarkup
for pbia. For getMarkup (b) can mean show a "" to the user just
to make
consumers more robust.
regards,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 17 July 2003 18:36
To: wsrp-interop@lists.oasis-open.org
Subject: RE: [wsrp-interop] Groups - WSRP Interop
SC call modified
Sorry my notes weren't clearer.
1a) We thought it would be useful
to have a convention for a value to
use in this common case. We preferred to take it from
the wsrp
namespace, but a convention can not define new values
for a
namespace. As a result we have an odd, but reasonable
value for the
convention.
3b) Apparently I wasn't clear enough.
As an optional element, the
MarkupContext can be missing. Some implementation
may prefer to
actually send it as a nil element. In both cases,
this will stimulate
the Consumer to invoke getMarkup. Returning a non-nil
MarkupContext
will be taken as having provided the markup for this
user
interaction.
4bi3) Yes, the Producer may throw
an OperatioFailed fault. In no case
is it sensible for a Consumer to presume that the
persistent state of
a POP may be written. Specifying this will likely
return normally
when no persistent state change was attempted
and return a fault
when a state change is attempted.
Rich Thompson
Andre Kramer
<andre.kramer@eu.citrix.com>
To:
wsrp-interop@lists.oasis-open.org
cc:
07/17/2003 01:15 PM
Subject: RE:
[wsrp-interop] Groups - WSRP
Interop SC
call modified
Apologies for joining late on the the call.
1a - the convention of userContextKey="wsrp:minimal"
is weird, but
it's just a convention, right? Some systems have a
guest system group
that can be used as the basis for a real userContextKey.
I don't understand 3.b:
"The signal for getting getMarkup called is a
nil MarkupContext or
missing." - or missing what? Could it be missing
mimetype? I would
like to be able to return a new preferredTitle with
and without
markup from pbia. Also, in future we may be passing
back a
CacheControl without markup.
4 b(producer side) i(POP being accessed)
3(PortletStateChange=readWrite -> make no sense,
throw
OperationFailed)
- in the general case this is just: "the producer
may throw an
Operation failed".
i.e. only makes "no sense" for JSR portlet?
My question is: how does a non-JSR168
portlet know that POP readWrite
is not allowed? We don't expect it to catch OperationFailed
and retry
with readOnly do we?
thanks,
Andre
-----Original Message-----
From: richt2@us.ibm.com [mailto:richt2@us.ibm.com]
Sent: 17 July 2003 17:35
To: wsrp-interop@lists.oasis-open.org
Subject: [wsrp-interop] Groups - WSRP Interop SC call
modified
WSRP Interop SC call has been modified
by Rich Thompson
(richt2@us.ibm.com).
Event description:
Shared timeslot with Conformance SC and biweekly TC
call.
USA Toll Free Number: 877-718-0936
USA Toll Number: +1-712-923-6878
PARTICIPANT PASSCODE: 402957
Agenda:
Date: Thursday, 17 July 2003
Time: 11:00am - 01:00pm Eastern Time
This event is one in a list of recurring
events.
Other upcoming dates include:
Thursday, 24 July 2003, 11:00am to
01:00pm Eastern Time
Thursday, 31 July 2003, 11:00am to 01:00pm Eastern
Time
Thursday, 07 August 2003, 11:00am to 01:00pm Eastern
Time
Thursday, 14 August 2003, 11:00am to 01:00pm Eastern
Time
Thursday, 21 August 2003, 11:00am to 01:00pm Eastern
Time
Thursday, 28 August 2003, 11:00am to 01:00pm Eastern
Time
View event details:
http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-interop/event.php?event_id=2503
PLEASE NOTE: If the above link
does not work for you, your email
application may be breaking the link into two pieces.
You may be
able to
copy and paste the entire link address into the address
field of your
web
browser.
Referenced Items
Date Name
Type
---- ----
----
17 Jul 2003 20030717 WSRP Interoperabil...
Minutes
You may leave a Technical Committee
at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]