Re: commit: ldap/servers/slapd/overlays pcache.c

["Pierangelo Masarati" <ando@sys-net.it>]

> (b) can be viewed as the current method by and large but there're
> differences:
>       - It is not crystal clear what you meant by the caching on a
>          per-client basis, but it seems to me that the pcache caching
>          is not performed on a per-client basis.

I mean caching on a per client identity base, i.e. the cache keeps track
of the identity of the requester, so there are different instances of the
same cached data for different users.  I understand this may be very
resource intensive and unnecessary when different users have the same
access level on the remote host, but this cannot be known in advance.  Of
course this should be very appealing when access to the remote server thru
the proxy is made by applicative identities, so the client identities are
a few and they are used to cache a lot of data.

>       - Hence, if multiple clients having different access controls
>          accessed the remote target server, the proxy cache will cache
>          their aggregate result. Without the same access control set up
>          at the proxy cache, a client can access data in the proxy cache
>          which are not allowed in the remote target server.

In this case, I think the cached tree should clearly distinguish between
clients.  One way would be to create subtrees of the cached data starting
from a tree made of the client's identities, e.g.

  + cn=Client 1,ou=People,dc=my,dc=org
    + dc=com
      + dc=example
        + ou=People
          + cn=Friend 1
          + cn=Friend 2

  + cn=Client 2,ou=People,dc=my,dc=org
    + dc=com
      + dc=example
        + ou=People
          + cn=Friend 1
          + cn=Friend 3
          + cn=Friend 4

Another solution would be to have a common cache, with anonymous data
directly contained in the objects, and special data contained in a
"cn=Cache" leaf, under the client's identity, e.g.

    + dc=com
      + dc=example
        + ou=People
          + cn=Friend 1
            + cn=Cache
              + owner=cn\3DClient 1\2Cou\3DPeople\2Cdc\3Dmy\2Cdc\3Dorg
              + owner=cn\3DClient 2\2Cou\3DPeople\2Cdc\3Dmy\2Cdc\3Dorg
          + cn=Friend 2
              + owner=cn\3DClient 1\2Cou\3DPeople\2Cdc\3Dmy\2Cdc\3Dorg
          + cn=Friend 3
              + owner=cn\3DClient 2\2Cou\3DPeople\2Cdc\3Dmy\2Cdc\3Dorg
          + cn=Friend 4
              + owner=cn\3DClient 2\2Cou\3DPeople\2Cdc\3Dmy\2Cdc\3Dorg

I see it a bit involved, but that's just food for thought

> (a) can be in fact viewed as a replica-initiated replication.

agree :)

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497