perfsonar development work

[ulisses <>]

Hi Jason

On 2006-09-24 21:19:27, Jason Zurawski wrote:
[...]
> >please note that what I tried to explain in the description I sent is that
> >the TOPSDataRequest also acts as a registration by including a time to 
> >live field
> >for the data request, this way the server will push the data each time the 
> >requested
> >data changes until the ttl expires
> >
[...]
> I understand that you want to save the amount of messages that need to 
> be defined and recognized, but it seems a little complex to roll two 
> functionalities (requesting data directly, registering for push data at 
> a later time) into a single message.  Perhaps you can explain why you 
> think a single message accomplishes this goal better?

to reduce the number of messages types, by adding a single field (time to live
of a question) you can ask the server to:

"keep me this information updated each time it is updated for this interval"

note that a separate message would be almost identical to a query

> >
> >+       TOPSClientRegisterResponse
> >
> >IMHO, not needed
> >  
> 
> Absolutely this is needed, how would it be possible to tell if this 
> succeeded or failed?  Even if its just a simple return of an error code, 
> it counts as a message type.

ok

> >+       [We may need submessages in this category, imitating the LS:]
> >+
> >+               ClientRegisterWithTOPS
> >+                       TOPSClientResponseFromTOPS
> >+
> >+               ClientUpdateRegistrationWithTOPS
> >+                       TOPSClientResponseFromTOPS
> >+
> >+               ClientKeepaliveWithTOPS
> >+                       TOPSClientResponseFromTOPS
> >+
> >+               ClientDe-registerWithTOPS
> >+                       TOPSClientResponseFromTOPS
> >+
> >
> >I would avoid that much amount of messages, IMHO I think that what i 
> >propose
> >is just enough for now and implements the required funcionality.
> >
> >
> >  
> 
> Right, you are proposing enough to get by for now, but these are all 
> valid use cases (if we are to follow the general template of how the LS 
> manages data/client interaction) and will eventually need to be dealt 
> with.  If your system will periodically 'clean up' the client 
> registrations by TTL it may be nice to have the ability to either 
> 're-request' with the same key (thus updating the TTL) either through 
> the standard registration mechanism or through some sort of keepalive.  
> I suppose de-registration is not required but may be nice if a client 
> wishes to be polite and not continue to utilize system resources when it 
> knows it will be going offline before a TTL is exceeded.

ok

but my point of view is to do not implement even any line of xml code, 
just leave it annotated in the documentation as "possible future directions" 
but
leave it completly un-implemented.

regards

        Ulisses