perfsonar development work

[ulisses <>]

Hi Jason!

Thanks for your comments

On 2006-09-19 10:48:37, Jason Zurawski wrote:
[...]
> My comments are at the bottom of the attached file.  So far I think it 
> looks fine, I have only commented on the need for some more specific 
> exchanges.

let's see:

--- tops-messages.txt.0 2006-09-18 16:16:51.000000000 +0200
+++ tops-messages.txt   2006-09-20 16:55:27.000000000 +0200
@@ -150,3 +150,60 @@
 of partial downloads. Selection of the database will be made with template 
xml file.


+LookupService (These should be in the LS format already developed, they are 
still
+               important to the TOPS though [create/respond to what happens])
+
+       RegisterWithLookupService
+               ResponseFromLookupService
+
+       UpdateRegistrationWithLookupService
+               ResponseFromLookupService
+
+       KeepaliveWithLookupService
+               ResponseFromLookupService
+
+       De-registerWithLookupService
+               ResponseFromLookupService
+

yes, that is the needed interaction with the Lookup Service


+TOPSDataRequest (client requests some or all of TOPS db info)
+       TOPSDataResponse
+
+

Ok

+TOPSClientRegisterRequest (client 'registers' with the TOPS, 

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

+                               TOPS provides
+                               some sort of 'key' back [client responsible 
for
+                               updating own key so it doesn't expire?  Will 
it
+                               expire?].  Will data push to registered 
clients
+                               when changes occur [triggers], the list of
+                               registered clients will exist on the TOPS
+                               somwhere?)

yes, it will have to store them somewhere because the stateless nature of 
the webservices.

but I think it is somewhat prepature to say where this should be stored.

If the data is uploaded to the tops with perfsonar messages, that method
would then check the registered clients and see if the modified data 
should push the updates o the clients.

please note that upload of the data is not yet contemplated.

if information is loaded in the database manually as it is contemplated 
right now, then the solution I'm thinking about is ugly/not 
clean... an external program should be implemented.

any suggestion about how to implement this? I think the Lookup service 
doesn't push data/triggers the clients.

+       TOPSClientRegisterResponse

IMHO, not needed

+
+
+
+       [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.

regards

        Ulisses