 |
 |
Thanks Lukasz! Then I'll coordinate with Andy and get back to you before I stick my fingers into the old client code. We have to do some work on the cmssw side as well and I'm not yet sure on which side we'll start. Cheers, Matevz On 01/10/12 02:26, Lukasz Janyst wrote: > Hi Matevz, > > 2011/12/17 Matevz Tadel <[log in to unmask]>: >>> well, I definitely don't want any kind of a "dial home" mechanism >>> in the client itself, this kind of stuff annoys people (it would annoy >>> me). We could, however, think of some sort of a plug-in mechanism >>> which would allow you to load your own monitoring library and do >>> whatever you want there. >> >> The client API still should implement part of the xrootd protocol that allows >> applications using it to send custom monitoring information, no? > > Sure! > >> In any case, >> all your secrets (DN, machine you are connecting from, files you are opening) >> are already available in the monitoring stream. > > Well, yes, but these are the parts necessary to fulfill the user's > request, and, by contacting the storage provider, the user expects > (probably doesn't like very much though) that these may be > logged/collected/forwarded for whatever purposes. Gathering custom > information, not strictly necessary to fulfill the request, is quite > different. That said, I agree that in certain cases, like optimizing > the transfers for the grid jobs, it is extremely useful. I just don't > want it enabled by default in order not to give the impression that we > are some kind of a Troyan Horse sending private info to some sort of a > Big Brother. People hate that kind of stuff. > >> What I'm after is the request-id kXR_set with "monitor" argument that calls >> XrdXrootdProtocol::do_Set_Mon() which then sends the application provided string >> + dict_id to the monitoring stream. This is implemented on the server, but not >> in the client. > > Sounds good. I am not really sure what you mean by dict_id though. > > Cheers, > Lukasz ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1