[wsrp-interfaces] [wsrp][interfaces] Summary: meeting 7/18

[Michael Freedman <Michael.Freedman@oracle.com>]

Detailed meeting notes aer attached [provided by susan levine].  Short
summary is though we talked about a few things the one item that we
discussed in detail and resolved was the issue of whether timeout hints
should be represented as durations or absolute times.  We decided that
durations were the way to go and that we would likely represent in
seconds as this gives us the most flexibility.
    -Mike-

--- Begin Message ---

• From: susan_levine@peoplesoft.com
• To: susan_levine@peoplesoft.com, Khurram_Mahmood@peoplesoft.com,Michael.Freedman@oracle.com
• Date: Thu, 18 Jul 2002 09:05:50 -0700

Mike-- detailed notes, transcription, etc.  Summary to follow late this
afternoon.


Mike:
update on refactoring.  begun to converse w/ a few of you, owe the broader
group a draft of what I'm thinking of, hopefully early next week.
second, since f2f, have a firmer draft of core interface, discussions now
on how to refine it, refactoring is one big question and there are others.
in addition , let's identify set of topics that haven't been addressed yet.
Open the floor to all of you to identify what we still need to discuss.

Let's use the email list to resolve the topics, but email hasn't been
successful in identifying the topics so far.

Do we want to use both of the meetings to make progress on refining draft,
or do we want to isolate teh progress we make in the 2 conf calls, maybe
use this conf call to discuss these additional topics, what would you guys
prefer?

Other:  use times for refining, because of time constraints in terms of
when we want to get this stuff out.
Other: my pref is regardless of how topics are identified (prob easier to
start discussions on email), in general we should resolve in a call that
allows higher bandwidth communication to occur.

Mike: but question is, what do we want to use this time for, now that we
have 2 tasks ahead of us: refine current draft, but we have 2 time slots
for that, wsrp and wsrp-wsia.  Then we also have need to discuss topics we
haven't id'ed yet.  One thing would be to try to make progress, hopefully
most of discussion will begin on email, then resolve on Thursday, rely on
Tuesday meeting to refine current proposal.  Other proposal is to use both
times to make progress on refinements, then turn attention to other things.

Other: is joint spec the full spec or is there another spec?
Mike: spec leads are working on them together, actual factoring is tbd,
Carsen and Rich are putting the words down on paper.
Other: in general is joint interface covering everything wsrp needs?

Mike: oh no, there's a lot of topics the interface does not yet address.
May choose not to, now focusing on core protocol, but there's a lot of
other topics and issues, just to throw a few out there:  caching support
thru protocol; supporting deep links - ability to from within a portlet to
link out to full application that lives behind it, but full app runs within
context that portlet provides to it; tech questions on markup
representation and soap; publishing one consumer's entities to a new
consumer - publishing in a development stage, production model how that
works; areas of the protocol that we're working on that we've made prelim
decisions at f2f that we have to reexamine - state parameters, sessions;

When should we begin to give them attention, and how do we want to segment
what we do in this meeting vs. the Tuesday meeting.

Alejandro (?): other things at wsia, webservices level as well, all those
issues you mention, fundamental issues with web services

Mike: trying to indicate there are 2 tasks that could be parallel -
refining details that we've currently been specifying, 2nd, trying to
articulate new function we have to deal with.

other: mike, I think my take would be better to kick off discussions
relatively soon, because we're on a tight time runway.  we may not resolve
immed, but at least we get started.

Mike: other thing is how do we want to view this particular time period
since there's also another time period.  Do we do cross talk across 2
meetings, or are they segragated.

other: for me the 2 meetings are the same focus.  you and alan have been
doing good job of keeping them ocmplimentary, so there's no overlap, I
would not organizationally constrain them, just keep working it out so it's
efficient.

mike; so I'm getting sense that preference is to id new areas, use alan and
myself to go thru mail list to get discuss, doesn't seem like we want to do
active brainstorming right now on what these would be.  please do your own
brainstorm, and email me at the list, don't need must explanation, just
enough to add to list of discussion topics.  discussion can continue on the
list.

then so I'd imagine we can turn to continue discussions of refinement of
current api, follow thru and clarify some of discussions from email thread.
is tehre a topic folks would like to start with?

other: one seems to be active, do we need both markup params and session
ids.  worth spending 5 minutes here to reach a conclusion?

mike: the only reason I hesitate is I've just spent yesterday going thru
spec with folks here, and I actually have reasonable understanding of the
variety of diff param state types that we have, I'll do a better job if I
write it up than if I try to explain over the phone what it is.  it's a
little diff than what we have in the api, but not much.  I believe it
covers gil's and alexandro's and yoshi's concerns.  we could discussion, or
delay until I have a chance to write it up and post it.  what would you
prefer?

other: efficiency says, you post it, then talk on Tuesday.

Mike: good

other: how many of wsrp guys have joined subcommittee phone calls? is
everybody there basically?
mike:  me, Carsten, rich, (a few others chime in)

other: mike will you have a chance to post it to the list prior to tuesday?
mike: i'm in a hotel in london over the weekend, will be able to write it
up, question is if hotel has email access.

mike: i'd ask folks to think about diff kinds of params or state that are
being managed; if i've come up with 4 types that need to represent, and we
have 4 places to represent them, we just need to modify a little bit some
of the behavior.  I think gil has tried to do this a little, but has just
id'ed effectively 2 of the types, yoshi's id'ed a 3rd type, the 4th hasn't
been discussed yet.

other: equivalence of persistent cookies is another one that's missing.

mike: will step back, point out what each of these things are that folks
are talking about, and one coherent way they could be represented in the
api.

other topics that are on threads?  If not I have one other topic, but may
be better to send out an email.  what were some of the other threads?

other: some discussion about expirey or timeout, what is needed, how
represented
mike: yes alan, do you want to update on what we talked about on tuesday?
alan: yeah, I don't have my notes though, I'm calling from home.

mike: I can do that then...  What I think we discussed talked about
question of number of things related to state that could expire - sessions,
markup parameters, rich had proposed a duration would be returned along
with state so consumer would have opportunity to understand when they could
toss the state.  recognizing that producer also manages state on a timeout
basis.  rather than a duration, shoul dit be a timestamp, the points I
tried to bring up on tues, timeout isn't absolute - session timeout works
like, based on duration from the last time I actively used this particular
state or received a request that referred to the state.  so that duration
was more applicable, because info is being passed as a hint, info to
consumer so it can better manage resources, as opposed to its anything
we're trying to keep synched with the producer.

other: so timeout ??? once generally ???

mike: we got to the q of timestamps to work if you require that the state
that's passed to producer is also returned by the producer on each
response, so timestamp can be updated each time.  is that the behavior we
want, or do we want it where the producer could choose not to return a
value and that would signify to consumer that they should use preexisting
value. key is it's important for consumer to detect whether the state has
changed or not, because it's actually potentially costly to consumer to
continue, to have to update the notion of what the referenced state is.  so
consumer wants to know if they have to bother, to avoid cost of doing write
at the point of every call.  the best scenario is one where consumer only
writes when it's actually changed.  and so whether or not we have a model
in which don't return anything indicates no change, we could have
alternative model where there's an indication of whether it changed is also
returned.

alejandro: ?

mike: it's largely in datastructures that are returned every time, but
that's...

alej: how does the producer know to change it?
mike: q of consumer knowing whether it's changed.  ie. if you're managing a
session id, do we force consumer to do a hash check when it receives the
return value to check if it's the same, or vs. having effective way of know
whether it's changed or not.  for instance markup parameters, things that
are opaque set of bytes, it's more peculiar to have consumer always have to
check.

alan: reopening a couple of questions, are we using timestamp as a checksum
on the response?

mike: no, i was indicating regardless of... 2 issues - issue that i was
introducing was if consumer wants to know if what it's receiveing back is
what it sent, have to provide some indication for that in the spec.  2 ways
it would happen.  1) separate attribute to timestamp/duration to indicate
change in response, or 2) absence of returning it would indicate that it
had not changed.  if we did the latter, duration would be the only thing
that made sense, timestamps have to be captured on every call.  duration
might be better even if we have the dirty bit thing, because of convenience
on consumer side.  but main q is how do we detect if it's changed.

alan: so in that sense, dirty bit is orthoganal to q of timestamp vs.
duration
mike: but it has to be answered first
other: duration is a consumer choice on how long it wants to wait, vs.
producer timestamp, up to you to wait for as long as you want...
mike: not sure I understand...
other: timestamp at which point the producer will consider this state to be
invalid.  it will do cleanup, consumer can cleanup as well.
other: can do that either way, timestamp or duration.
other: please reexplain dirty bit
mike: consumer running in load balanced environment, receiving state from
producer, need to know whether it's change, need to know if I have to
change it in my replicated store, which is an expensive operation.  want to
know if I have to write the value on each request, or if I don't have to
write because it's the same as it was before.
other: if we use duration, ...
mike: duration and timestamp are never guaranteed to be exact, can't synch
the two machines up, so if I return a duration of 5 minutes, 5 minutes to
me might be different... you can't guarantee it.  all that this has to be
looked at as just a hint to teh consumer because without providing the hint
the scope is almost never, when the user logs out you can get rid of it.
seems a long time for what might be transient state.
alej: still w/ having timestamp you have network latency in there...
mike: yeah that was the point, using either one, they don't impact your
expectation of when you make a call whether you get dirty info or not, you
might get dirty info on every call you make, less common in case of
sessionid, but more for markup parameters in that case.  and so, you want
to be able to understnad the diff between when you call and return and it
didn't change, vs. when it did change, independent of whether I can free it
up because it's not being used within the frequency of the hint.

alej: hint for the consumer needs to be sent to producer by consumer to
verify whether what they have is valid or not, then also how does the
response represented from producer to say it's invalid or valid, or new
data, so really there are three concepts in there.

mike: please run thru all three

alej: 1) producer sends to consumer, says this is the amount of time, hint
about that for validity. 2) piece of data or info that the consumer must
send to prod to determine if it's still valid..

mike: please explain
alej: in simplest case, like a version id that's embedded int he markup, in
order to verify the consumer must send that particular piece of info back
to producer, and say is this valid. so you don't have to send whole
resource back, just the id, so that's number 2.
mike: yeah and I htink for kinds of things we're talking about, it does not
apply, applies for content but not for state.  haven't yet discussed
caching and content and what you just described there is a technique for
managing content caching
alej: wasn't thinking about content but more explainable in terms of
content...
mike: i think for state our expectation is you never go thru the bother of
trying to validate state you're about to pss to prod, prod will either just
ignore the state when it receives it because it's no longer valid, or use
it.  in either case may update state or return new state
alej: so the 2nd concept is a piece of info, whether whole state, or
representative of that state that cons sends to prod.
mike: yeah, you send the state itself.
alej: trying to step back to higher levels, in one case it's 24 byte data,
in another case 24kbyte data. represents state of the consumer.
3rd one is what you get back, saying, no it's not valid, or not only invlid
but here's the new state or the state itself.
mike: i'm still having difficulty understnading what are the semantics
behind prod deciding what the time to live for the state would be?  is
there a rule of thumb or...
other: idea here is that the prod already has an internal notion of this,
because they rcognize it's running in connectionless environment, prod
wants to be able to clean up resources, so problem is way we've defined
protocol in addition to resources being in prod, info was transferred to
consumer which it expects consumer to maintain in its lifecycle.  so teh
duration is likely corresponds to duration prod is using to maintain state
in its own world to give indication when cons also could get rid of state.
alan: if you don't talk to me at least once every x minutes then the state
will be invalidated.
mike: in fact it's just a hint consumer is free to toss anytime they want
to.  we can't require cons maintain prod state for as long as it needs it,
that's not the way connectionless stuff works.  like cookies, can't require
you get the cookie back, have to deal with situation where it goes away.
alan: key part of q relative to duration vs. timestamp, timestamp makes it
dependent on synching clocks
mike: and more cumbersome for both, to the prod it is a duration, have to
manufacture timestamp based on duration, for consumer it's a duration, have
to demanufacture it from the timestamp.  yoshi's orig concern was duration
and network latency, hoping that having gone thru this discussion,
understanding this is a hint rather than an absolute overcomes that kind of
concern.
other: i think if anything it will tend to cause consumer to cleanup after
producer does.  if everyone does it right as timeouts happen, that's the
right model.
alej: my question, i don't think it's a timeout in the sense of ?? some
cases might not be relevant, almost everyone prefers duration and concern
about synching clocks, I accept it.
mike: okay great, so the new thing we haven't addressed is the question of
how does the consumer recognize whether the response is a dirtied form of
what was passed on teh request.  could push back to you rich, to clarify in
the spec.
rich: okay, as we've commented in other places, we've tried to separate
optimization from what's logically there, might just put this in as a
boolean flag now, then later see if it collapses to if you send it back at
all it's not changed.
mike: put comment in spec that optimization needs to be acounted for...
other: before we move off expires in duration.  what's the appropriate
units her?  the current draft says seconds.  the 2 that make sense to me is
seconds or minutes, i'm slightly in favor of minutes.
mike: i think minutes are fine enough granularity because if you're asking
cons to manage something for less than a minute, what's the point?
other: i agree, but can't we accomplish minutes by using seconds and then
allow for granularityh is less than what we expected?
other:  for instance, mail handler on yahoo times out login after 8 hours,
28 or 29thousand seconds, still can declare with seconds.
other: i would look at kind of state it will apply to and see what's
commonly done in appservers today, like sessions and entity state, what
servlets do, how they represent expirey of state internally to producer,
look at diff app server models.
alej: one thing to look at is there's a proposal on w3c on akamai and
others to define for content and diff resources caching mechanisms, some of
those might be relevant here.
mike: i think caching, we're going to be representing differently than this
mechanism we're talking about.
other: but it's similar in that you're asking somebody to store for you.
thinking about yahoo case, that's the longest timeout I've seen, and still
reasonably represented as seconds, that's the granularity that makes sense,
enables casees where minutes would be difficult.
mike: one thing we lose if we go to minutes is things like 20 seconds. it's
fine either way.  inconvenience of seconds when mostlyminutes is the righ
tmetric is people having to do the conversion.  some admin will have to sit
down and write 29000 in a declaration file when what they really meant was
8 hours.  have to do the math.
jeff:  ui is often able to do that for them.
mike: good point.  represented over protocol as seconds, but to user as
minutes.
other: another one is  that we'd included an expires duration in the entity
concept at the same time we included entity state pushed to consumer.  If
all entities configurations are persisitent, then expires does not belong
there.  if a prod is not storing anything, pushing to consumer...   entity
state and expires is in teh entity context.
mike: maybe I read it wrong, that it was effectively the collapsing of
markup parameters and session id, each represents the entity's state, by
reference or by the state itself. was that what you meant?
other: no it wasn't.  that would be scoped wrong... i need to improve
description.  if prod is not supporting persistence in order to support
create entity with unique confi, has to be able to push the config back to
the consumer, and persist it there.

alej: clarification: I though prod handles
mike: thought cons was only thing that stored persistent informaiton, is
that the question?
alej: right
mike: that's what I'm trying to clarify
other: the only thing stored in a persistent way is the consumer handle not
the entity handle
alej: if cons is not able to keep handle persistent then it must release
the handle.  because release handle has to be called before prod releases.
mike: in general that is the case
other: at f2f kept persistent connectin of entities, threw out concept of
transitory entities.
mike: entity is really collection of customizations that define the
particular representation in the consumer.

it's 9 oclock in the states, any final comments?

is there another call after this one?

no. last week's was cancelled, next one is next week.

is thomas on the line?

question: do we have an estimate of what quarter of next year we'll come
out with this?

other: no one has agreed yet to postpone timeline, which was december
mike: at f2f we kicked it out a few weeks, internal draft beginning of
september, then will refine, take public comments thru mid november, hope
is to have final draft, f2f, and hopefully just a week or two of
refinements and can pubilsh into oasis approval process in december.

realistically end of first quarter, right?
mike: yes, challenge is over next 4 weeks can we get to a complete spec,
I'm not either optimistic or pessimistic now.

--- End Message ---