perfsonar development work

[ulisses <>]

Hi Vedrin!

On 2006-09-07 01:58:55, Vedrin Jeliazkov wrote:
[...]
> Ulisses, I guess that by "client that registers the data" you actually mean 
> a
> service which registers its capabilities in LS, right? In my further 
> comments
> below I'm assuming this.

yes, that's it.

> > Hi!
> > 
> > Yes, that's right. We haven't thought about it yet.
> > 
> > [ I CC-ed the e-mail to Vedrin. ]
> > 
> > Vedrin, what do you think: what would be the best way (from client point 
> > of view) for determining such LS parameters as TTL:
> 
> Maciej, if your question refers only to visualization clients (which would
> access the LS in a read-only mode), than I see two options:
> 
> 1) the client doesn't receive/process resource TTLs at all; instead, it
> assumes that if the LS has returned a pointer to a certain resource, then 
> it's
> reasonable to consider the resource as being available (alive);
> 
> 2) the LS provides a TTL attribute for each returned resource (or set of
> resources) and the client is free to make its own decisions based on this 
> info
> (e.g. cache the resource pointer while the returned TTL has not expired,
> consider some resource as unstable if its remaining TTL is too short, ignore
> the TTL attribute, etc...).

[...]

to summarize:

- returning the TTL from the LS means the LS can stablish the policy. eg: 
informing
  that the requested TTL is too large or customizing the TTL depending on the 
  size of the storage.

- specifying the TTL as a parameter to the LS will be interesting because each
  service knows it's needs, more than the LS.

I think that the simple, the best:

  the registrator sets the desired value for the TTL.
  the LS returns the effective TTL.

in think I will define this way for the TOPS notifications

        Ulisses