perfsonar development work

[Jason Zurawski <>]

Ulisses;

> > Then perhaps one of the other developers could answer the question as to 
> > how the 'conversion to DOM' happens in your service.  If you are not 
> > implicitly calling a routine (like toDOM()) then I am not sure I really 
> > know where your problem lies or how I could help you any further.
> >     
>
> who I should contact?
>
>   

Who was the one who originally helped you design this service?  Perhaps 
they have a little better insight as to how you are dealing with your 
message passing than I do.

> > > > By message sequences Loukik means what the purpose of the request and 
> > > > the response are, and what they general format should be.  I don't 
> > > > believe you have ever roughed out an 'expected' sequence of exchanges to 
> > > > this service (i.e. a request document format and the resulting response 
> > > > document format).  
> > > >    
> > > >         
> > > for now, it's only one request:
> > >
> > > 	- "please dump me the entire topology" 
> > >
> > > and one reply:
> > >
> > >         - "just dump all elements"
> > >         
> > > that are the current requirements
> > >
> > >  
> > >       
> > Even though these are simply enough, an attempt should be made to define 
> > the request and the response formats.  How does 'dumpt the entire 
> > topology' get translated into XML, 
> >     
>
> That is the xml I was sending in mails last days
>
>   

Alright, but the point I am trying to make is that even if it seems 
simple and you know it very well, not everyone else does.  We should try 
to make these artifacts and store them in svn so that others could try 
to help you when there is a problem, as well as making sure that this 
service behaves like all others in the framework when given specific input.


> > are you just doing the same action no 
> > matter what the actual request message reports?
> >     
>
> yes, full download of the database doesn't need parameters now, but I recall now 
> that in the future this request (can/will include a timestamp value) which 
> means download the topology that existed at that date. Other requests can use 
> this parameter too. 
>
>   

All of this information you are giving me is valuable, which is why I 
hope you can start to make these documents so we can continue to help you.


> > In the future these will no doubt change, and there may be a need to 
> > have various request/response messages.  In the interest of expansion 
> > these issues should be dealt with.
> >
> >     
> > > > Even though you have already started the physical 
> > > > service, it would be nice for me to see what your request and responses 
> > > > would look like.  
> > > >    
> > > >         
> > > future developments can include:
> > >
> > > - Retrieval specific elements of the topology, that is do partial download 
> > > of the database
> > >
> > > 	From 
> > > 	http://wiki.perfsonar.net/jra1-wiki/index.php/Topology_Service_resources # Required interactions
> > > 	#  Retrieval of topology information: Clients need to have the 
> > > 	possibility to retrieve network topology information. It needs to be 
> > > 	discussed which granularity is needed (whole networks, a component 
> > > 	and all neighbors, etc).
> > >
> > > - Register at the Tops in order to be notified when the topology or an 
> > > specific element of the topology has been updated
> > >
> > > 	From 
> > > 	http://wiki.perfsonar.net/jra1-wiki/index.php/Topology_Service_resources # Required interactions
> > > 	# Client notification: It might be interesting for clients to 
> > > 	register themselves at a ToS and to be informed about changes in the 
> > > 	topology automatically. 
> > >
> > >  
> > >       
> > OK, then along with the previous request/response messages, examples 
> > should be designed for these as well.
> >     
>
> what rules should I follow? it is not clear for me
>
>   

Have you read the other documents from svn as I asked?  It should start 
to become easier once you see how the documents are sent to something 
like the LS, and the appropriate response returns (i.e. register this 
MA's information to an LS, and here is a success message for the 
registration).  You don't need to know everything about XML, Schema, 
Java, or Web Services to  get started;  all you really need is to write 
down (using the other examples) what needs to be accomplished with each 
message type that you have described previously.

> > The ideas seem ok, so the next step is to make some instance documents 
> > in XML that match these ideas.  Follow what the others have done in svn 
> > so far.
> >     
>
> ok, I will try but I don't have clear the rules 
>
>
>   


There are no 'rules' really, all we are asking you to do is look at the 
other examples, and decide what things are necessary for a 'request' to 
happen.  The syntax will come in time, the semantics are much more 
important, and you know those much better than I do.  You noted above 
that you may need a time stamp.  You also noted you could request a 
specific piece of info from the database, or request *everything* from 
the database.  These are all requirements that go into the design of a 
request.  We don't have all the answers, and we also don't really know 
exactly what you are trying to accomplish with the topo stuff.  I can 
help you out as much as I am able to, but I can't really design the 
entire thing.

Please look at the examples, as best as you can decide what a request 
should look like, and its appropriate response.  It will not be right 
the first time, and thats ok because we will help you make it right over 
time.  

-jason