OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

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

Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism


I definitely agree - a full algorithm would be complicated. But what Yossi
suggested is, in essence, a very simple approach to this problem that will
solve 90% of the "scoping" of the cache entries issues. It's a good first

I propose going through with it. I can easily add something to my proposal.


-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Tue, September 24, 2002 18:22
To: Tamari, Yossi
Cc: Gil Tayar; 'Rex Brooks'; wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism

Yossi - I completely agree that for an optimal performance there must be a
way for the producer to generate a cache key from all the input parameters
and to let the consumer know how this key was generated. This way the
consumer can determin when to request new markup or when to use the cached
Hoewever a definition of such a key generation algorithm will be quite
difficult and I wonder if we can agree upon one in v1.0 of the spec.
The current proposal by Gil would correspond to a key generation algorithm
that uses the full input space for the key. So it does not need to
explicitly pass this key but can imply it. Of course this is not as
efficient as it could be (the cache size will be to large), but it is a
first step in the right direction ;-)

Best regards
Carsten Leue

Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401

|         |           "Tamari, Yossi"  |
|         |           <yossi.tamari@sap|
|         |           .com>            |
|         |                            |
|         |           09/24/2002 04:08 |
|         |           PM               |
  |       To:       "'Rex Brooks'" <rexb@starbourne.com>, Gil Tayar
<Gil.Tayar@webcollage.com>, wsrp-wsia@lists.oasis-open.org    |
  |       cc:
  |       Subject:  RE: [wsrp-wsia] [I#97] Caching Mechanism

Hi Rex,

I'm still unclear as to what you mean. The caching we are talking about
here is done by the consumer, not the producer. This means the portal is
caching pages for its users. This is already done today by most (if not
all) portals). We are not discussing caching by the producer. We do not
need to put it in the spec, but I don't see any way to prevent producers
from persisting personal user information (whether I like it or not).

      -----Original Message-----
      From: Rex Brooks [mailto:rexb@starbourne.com]
      Sent: Tuesday, September 24, 2002 4:27 PM
      To: Gil Tayar; wsrp-wsia@lists.oasis-open.org
      Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism

      Hi Gil,

      I agree that caching is important, I'm just not sure it is wise in
      this version, at least not to the extent that Yossi was discussing.
      Also caching is different than archiving or saving personalization
      information for later use in a database, and I didn't consider that.
      As long as it is easy to retroactively require that personal
      information be destroyed after a single use without explicit, item by
      item, permission from the end user whose information is being
      handled, it shouldn't turn into a bottleneck later. I haven't thought
      about what kind of mechanism that might be or how to do it. I know
      bots could be constructed that end users could activate when closing
      down their connection to a web service provider which would verify if
      the information had been destroyed, or at least check to see that the
      web server log showed that, so I suppose a notification of some sort
      upon the destruction of the session might be worth considering, but
      not for this version certainly.


      At 6:35 AM +0300 9/24/02, Gil Tayar wrote:
            it was the decision in the F2F to bring a simple proposition to
            the table. That is what I am doing. It may be rejected, but
            nonetheless, it was the concensus that caching is very

                  -----Original Message-----
                  From: Rex Brooks [mailto:rexb@starbourne.com]
                  Sent: Mon, September 23, 2002 15:59
                  To: Tamari, Yossi; 'Gil Tayar';
                  Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
                  Is this something that the spec needs to address?

                  Just a heads up, but, user information is ultimately
                  going to be protected against copying anywhere except
                  into a file for that particular user that must be
                  destroyed after any single use without the specific
                  itemized and specialized permission of the user, so you
                  won't have this particular problem.

                  This WILL be a scalability problem, but it certainly
                  won't be confined to Web Services. Now in the case of
                  corporate portals with special permissions required of
                  and by its employees, this could become an issue, but
                  that is one for which our TCs need to liaise with
                  HR-XML.org and the Web Security Standards groups. to
                  ensure legal conformance and interoperability. The one
                  thing I can say coming from the HumanMarkup TC is that
                  this issue won't be dealt with in any kind of official
                  specification submission until this time next year at the

                  I don't think this particular kind of caching should be
                  in the first version, and probably shouldn't be
                  formalized until after the other standards groups do
                  their work. As for larger caching issues, I think this
                  tendency toward particularization on micro-issues, which
                  this example only typifies, is a very bad idea.

                  I don't know about all of you, but I really don't want to
                  be revising endlessly to get back into conformance with
                  other specifications in v.2.0.6, 2.0.7, etc., ad

                  I bring this up here, but it applies across the board.


                  At 12:52 PM +0200 9/23/02, Tamari, Yossi wrote:
                        The need for different scopes of caching:
                        Say I have a portlet that is cached by the
                        consumer, scoped to the producer. Say this portlet
                        is capable of personalization through the edit
                        First user U1 asks for this portlet and gets his
                        personalized content. Then user U2 asks for the
                        same portlet, but his personalization info is
                        different. He will get the cached portlet with U1's
                        personalization! Now assume user U1 also went into
                        edit mode, got the edit page with his current
                        settings, and pressed cancel. The cache was not
                        invalidated. Now U2 goes into edit mode - he will
                        get the cached edit page with U1's choices as his
                        This demonstrates the need for user-scoped caching.

                        The need for session scoped caching is demonstrated
                        by: a user opens a portal page, a session is
                        created for a portlet in this page, the user
                        navigates in this portlet (actions), thereby
                        changing the session information. He ends up with
                        page #4 (of the portlet), and some session
                        information that is related to how he got to this
                        page. page #4 is cached. Now he closes his browser
                        and open a new one. The session is killed. He
                        navigates to page #4 through the cache, never
                        actually going to the producer. Then he navigates
                        to page #5, forcing a WSRP request to the producer.
                        However, the producer can't service this request -
                        it needs the information that was gathered in pages

                        It is possible to create a portlet that will not
                        have this problem, by encoding all information in
                        the URL, but I don't think it is reasonable to
                        demand this.

                        In the F2F discussion about caching we suggested
                        using, in addition to the mechanism you suggest,
                        all the parameters of the action as keys to the
                        cache, and allowing a portlet to define which
                        parameters can be ignored. I was missing this in
                        your suggestion. One way to implement this is by
                        telling the producer it needs to encode these
                        parameters into the validationTag, but unless the
                        consumer knows the encoding algorithm it does not
                        really work

                              -----Original Message-----
                              From: Gil Tayar
                              Sent: Monday, September 23, 2002 12:44 PM
                              To: Tamari, Yossi;
                              Subject: RE: [wsrp-wsia] [I#97] Caching
                              The spec says that the "expires" is a
                              placeholder for a real caching mechanism. My
                              proposal was intended to replace it.

                              I didn't say it works around the need for
                              other scopes (I'm not certain what those
                              needs are). I said that it doesn't look to
                              have problems that the other scopes do have.


                                    -----Original Message-----
                                    From: Tamari, Yossi
                                    Sent: Mon, September 23, 2002 10:47
                                    To: 'Gil Tayar';
                                    Subject: RE: [wsrp-wsia] [I#97] Caching
                                    Hi Gil,

                                    I must be misreading the spec, because
                                    it seems to me that expires is an int
                                    number of seconds currently in the spec
                                    (which may not be the the right way,
                                    but that's what was decided).

                                    As for scoping to the Producer, can you
                                    please explain how that works around
                                    the need for other scopes (unless they
                                    are coded into the validationTag)?

                                          -----Original Message-----
                                          From: Gil Tayar
                                          Sent: Monday, September 23, 2002
                                          7:23 AM
                                          Subject: RE: [wsrp-wsia] [I#97]
                                          Caching Mechanism
                                          Good questions.

                                          On the scope question, I would
                                          scope it to the Producer. This is
                                          the easiest and works around
                                          problems with the other scopes.

                                          On the type of time - the
                                          validUntil is a "date-time" field
                                          just like Expires is, and I
                                          suggest we use the xsd:dateTime
                                          type for it (or whatever its
                                          exact name is). This means that
                                          the time is an absolute time.
                                                -----Original Message-----
                                                From: Tamari, Yossi

                                                Sent: Thu, September 19,
                                                2002 17:56
                                                To: 'Gil Tayar';

                                                Subject: RE: [wsrp-wsia]
                                                [I#97] Caching Mechanism
                                                What is the scope of the
                                                cached fragments? user?
                                                session? entity? Should
                                                this be explicitly returned
                                                in the markupResponse or in
                                                the metadata of the entity,
                                                or does the entity encode
                                                it into the validationTag
                                                if it wants to?

                                                Should we return the
                                                (absolute) expiration time
                                                or the (relative) amount of
                                                time until expiration? on
                                                the "expires" field I was
                                                for expiration time but I
                                                was out-voted.


                                                      From: Gil Tayar

                                                      Sent: Thursday,
                                                      September 19, 2002
                                                      9:03 AM

                                                      Subject: [wsrp-wsia]
                                                      [I#97] Caching
                                                      Topic: interface
                                                      Class:  Technical
                                                      Title: Caching
                                                      Document Section:
                                                      I am submitting the
                                                      following proposition
                                                      to the committee as a
                                                      proposition for
                                                      dealing with caching
                                                      of the markup. This
                                                      proposition deals
                                                      with "Expires"-like
                                                      methods of caching,
                                                      along with

                                                      type of caching. I
                                                      believe it is simple
                                                      enough to be included
                                                      in the v1.0 spec.

                                                      Caching Proposal
                                                      [The proposal is
                                                      described as edits to
                                                      the spec]

                                                      6.1 Operations

                                                      [instead of expires
                                                      in markupResponse,
                                                      add the following]
                                                      cacheControl: A data
                                                      structure, defined in
                                                      Section 11, which
                                                      includes information
                                                      which CAN be used by
                                                      the Consumer to cache
                                                      the markup. This
                                                      structure includes:
                                                          validUntil: The
                                                      time at which the
                                                      markup is valid.
                                                      Until that time the
                                                      Consumer CAN use its
                                                      cache entry instead
                                                      of calling getMarkup.
                                                      After this time
                                                      passes, the Consumer
                                                      MAY continue to use
                                                      this cache entry, but
                                                      only after validating
                                                      it with a getMarkup
                                                      operation, using the
                                                      validationTag below,
                                                      if given.

                                                      The Consumer MUST
                                                      store this tag along
                                                      with the markup while
                                                      the markup is valid.
                                                      This enables the
                                                      Producer to use this
                                                      tag to invalidate the
                                                      cache entry by
                                                      sending an
                                                      in the
                                                      operation. After the
                                                      markup expires, the
                                                      Consumer CAN send the
                                                      validationTag in the
                                                      markupResponse to
                                                      indicate that it
                                                      still has the markup
                                                      but would like to
                                                      validate it. The
                                                      Producer returns a
                                                      fault response [TBD]
                                                      to indicate that the
                                                      markup is still
                                                      valid, otherwise if
                                                      it returns markup ,
                                                      the Consumer MUST
                                                      invalidate the old

                                                      [add to markupContext
                                                      the following field]
                                                      This field CAN be
                                                      sent to indicate that
                                                      the Consumer has
                                                      cached markup (which
                                                      was tagged by the
                                                      Producer with this
                                                      value) and wishes to
                                                      check whether it is
                                                      still valid. See
                                                      validationTag in
                                                      markupResponse for
                                                      more information.

                                                      6.1 Operations
                                                      [add the following
                                                      field to

                                                      : If the Producer
                                                      returned this value,
                                                      the Consumer MUST
                                                      expire all markup-s
                                                      who's validationTag
                                                      begins with this
                                                      value. The Consumer
                                                      MUST not call
                                                      getMarkup with these
                                                      invalidationTag-s to
                                                      validate these
                                                      expired markup-s.

                                                      [add these fields to
                                                      the relevant places
                                                      in section 11]


                  Rex Brooks
                  Starbourne Communications Design
                  1361-A Addison, Berkeley, CA 94702 *510-849-2309
                  http://www.starbourne.com * rexb@starbourne.com


      Rex Brooks
      Starbourne Communications Design
      1361-A Addison, Berkeley, CA 94702 *510-849-2309
      http://www.starbourne.com * rexb@starbourne.com

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC