perfsonar development work

[Jason Zurawski <>]

Maciej;

>>  * Storage Structure Change - This is the area that I am exploring next
>> and I think will also be very beneficial.  Currently the service info
>> and data are all tied to the single control structure for time.  This
>> means that when the service expires, so does the data.  This works well
>> for services in which the data will never change, but is problematic for
>> dynamic data sets/.  The Topology Service for example will experience
>> constantly entering and leaving information, and shouldn't have to keep
>> records on what needs deleting from the LS.  It would be much easier to
>> let the 'data' expire on its own (hence freeing the services from
>> needing to perform 'deregister bookeeping').  When the dynamic services
>> 'register' or 'update' then, the older stuff will never be touched and
>> eventually will be removed.  This will require a more frequent update
>> interval.  This leads to the last item...
>
> We could discuss it a bit (or a way how to implement it) during Zagreb
> meeting if you will be there. I'll add it to Szymon's list of proposed
> topics for the meeting.

I will not be attending in person, and am still waiting for an answer
regarding video conference availability.  It may make more sense to just
discuss the issue via email, I can try to write down some notes
regarding the dynamic services and the recent performance tests we have
done to show how registration degrades over time.

-jason