wsrp-coord message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp-coord] Comments on Events Semantics Doc
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp-coord@lists.oasis-open.org
- Date: Thu, 16 Sep 2004 08:33:47 -0400
It is good to work through how we got
to the current state ...
3. The publishedEvents are expected
to be defined by the portlet in some manner, though this could be via an
include of someone else's definitions. I believe the thought behind handledEvents
being different was a greater likelihood that these would be from another
namespace. It would be more reliable if they were of type EventDescription
as well.
4. A portlet handling a SetCustomerID
event could easily be expected to generate other events related to the
side effects of doing that update. In general, handling an event should
be expected to generate the same events that processing the equivalent
from a user's interaction with the portlet's markup, with the exception
of generating the event which is being processed.
5. The use case for Consumers that only
handle simple payloads is Consumers who have already have an event distribution
engine and that engine only handles simple payloads.
Do you think we need to open additional
issues related to any of these areas or just discuss them within the current
set?
Rich
"Goldstein, Scott"
<Scott.Goldstein@vignette.com>
09/15/2004 08:35 PM
|
To
| Rich Thompson/Watson/IBM@IBMUS,
<wsrp-coord@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp-coord] Comments
on Events Semantics Doc |
|
Thanks for the comments, Rich.
1. Sounds
good.
2. Sorry.
My misunderstanding.
3. I’m
not sure I’m following what you mean by, “if we make it an EventDescription[],
it would mean that the schemas defining such interesting events would need
to be reachable so that they could be dealt with via an include”. Could
you elaborate? Also, how is having this field be of type, EventDescription[],
different from having the publishedEvents field of type EventDescription[]?
4. I
understand the advantage of flexibility. However, it’s not clear
to me when it would be used. This is why I was curious if anyone
had any specific use cases. The concern I have with it is that it
opens up the possibility of performance problems and even infinite recursion.
Therefore, you would want to implement a Consumer to limit the number
of chained events it would handle before calling getMarkup(). On
the nth event, then, you could call the handleEvents() operation with a
flag stating that the Consumer will no longer send events. A portlet
may then be able to react to this, thereby putting itself in a proper state
in order to serve the subsequent getMarkup() call. Though an infinite
loop is unlikely, it’s definitely possible, especially in the case where
the Consumer allows event mapping within a configuration screen and the
administrator maps the events in a feedback fashion. Anyone else
have thoughts on this?
5. Why
would it be beneficial for a Consumer to only handle events that were simple?
I don’t see it as being easier to implement, since the Consumer
can pass data of type any from one message to the next without actually
reading it. Was there another purpose behind it?
Thanks.
Scott
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Tuesday, September 14, 2004 2:14 PM
To: wsrp-coord@lists.oasis-open.org
Subject: Re: [wsrp-coord] Comments on Events Semantics Doc
My take:
1. I would like to turn the open questions into an issues list that we
systematically work our way through. I think this will need people to step
up to fleshing out the pros and cons of the various issues so that a decision
can be reached. This will likely be a list that grows a bit as people now
see the changes we have discussed in the broader context of the spec.
2. The discussion about '/' or '.' was left open the last time it was discussed.
3. I think the reason we had set the handled events as QName[] was that
portlets could easily be handled events defined in other namespaces. I
see the issue you raise ... if we make it an EventDescription[], it would
mean that the schemas defining such interesting events would need to be
reachable so that they could be dealt with via an include.
4. The semantics are that an interaction is an event that has been serialized
to markup. I can't remember an eventing system where single generations
of events ever dominated, though the number of generations is often small.
5. This question deals with how a Consumer advertises its capabilities.
The axis discussed included doing event distribution, only distributing
events whose payloads are of type string and full support for distributing
generated events.
Rich
"Goldstein, Scott"
<Scott.Goldstein@vignette.com>
09/14/2004 02:55 PM
|
To
| <wsrp-coord@lists.oasis-open.org>
|
cc
|
|
Subject
| [wsrp-coord] Comments on
Events Semantics Doc |
|
Rich mentioned in the last conference call that now was a good time to
bring up questions/issues with the current eventing semantics doc, given
that it’s being put into the 2.0 spec. Here are our comments:
1. There are
still a significant number of open questions listed in the doc which appear
not to have made it into the WSRP 2.0 spec draft. Will we continue
working with the semantics doc and then push the changes into the WSRP
2.0 spec? Or, does it make sense to add the open questions to the
WSRP 2.0? It doesn’t seem to make sense at this point to apply changes
to both docs.
2. Minor -
In the suggested hierarchy of event names, we had discussed changing the
“/”’s to “.”’s. I see that the open question about confusion
with Xpath is still there. I don’t recall, however, anyone having
a problem changing to “.”’s. Any thoughts on this?
3. In the PortletDescription,
why is the type of the handleEvents element a QName[] instead of a an EventDescription[]?
Imagine the following scenario: I consume a portlet which states
that it can receive events of name, “ns1:zipCodeEvent”. Imagine
that I consume another portlet which states that it published an event
with name, “n55:myZipCodeEvent”, data type, “xsd:string”, and description,
“The current zip code selected.” As a portal administrator, I may
want to map the published, “n55:myZipCodeEvent” to be received by the
first portlet as, “ns1:zipCodeEvent”. Unfortunately, without a
data type and description, I don’t know what the first portlet is expected.
However, if handleEvents was an EventDescription[], all of this information
would be provided, facilitating this mapping.
4. Can someone
provide a specific use case around event chaining (returning events from
a handleEvents() calls)? I’m having trouble seeing the need for
this. The only possibility that I can some up with, is for sending
an ACK, which might be useful based on the way we’re defining the Consumer
as an intelligent entity capable of making the decision not to send events.
Is this the case that has come up or are there others? Also,
would the sending of ACKs be our best practice suggestion of verifying
event propagation?
5. Open Question
#3 – What is the difference between a simpleEvent and a complexEvent?
Thanks.
Scott
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]