Print

Print


  Hi Fabrizio,

On Mon, Aug 23, 2004 at 10:16:13AM +0200, Fabrizio Furano wrote:
>  sorry for the delay, but the department opened today. Previously I was 
> at home using the ugliest gprs. Now I am in the office booting the 
> machines...
> 
>  Is Andy coming here tomorrow?

  I thought it was Thursday. At this point we should probably just discuss
it in the weekly phone meeting tomorrow and then we can continue it if
necessary once Andy is in Padova.

                                   Pete



> Peter Elmer wrote:
> >  [Move discussion to the new xrootd mailing list from BaBar KanSOS HN]
> >
> >  Hi Fabrizio,
> >
> >  Perhaps you, Heinz and I could talk by phone briefly after lunch? Are you
> >available? Heinz, do you have any time?
> >
> >                                   Pete
> >
> >On Thu, Aug 19, 2004 at 10:35:05AM +0000, Fabrizio Furano wrote:
> >
> >>Hi all,
> >>
> >>I am back after the vacations outage....
> >>
> >>Yes, I looked at the code, and I think that the fastest way to get to 
> >>the result is to borrow some components from xrootd/heinz's client. 
> >>These could be used to substitute the few classes that TXNetfile uses 
> >>from root.
> >>
> >>I see mainly three points in the work to do, and I have answers for 
> >>two of them:
> >>
> >>- client sockets: I can build a simple socket class similar to TSocket 
> >>and use it from TXSocket.
> >>- private members coming from TNetfile/TFile: they are not many, 5-7 
> >>data members to incorporate in the new interface
> >>- Configuration flags and parameters: now they come from TEnv. What do 
> >>you suggest for them in the new client? We might use:
> >> - envvars... I know Pete says they are *evil*
> >> - pass to the ctor some optional data structure
> >> - use the default parameters as constants. After all, they have
> >>   never been changed...
> >>
> >>
> >>My suggestion, to speed up the work, is to start from the latest 
> >>TXNetFile inside root, and making it independent from the root classes 
> >>while still in the framework. When the result is reached, then we can 
> >>deal with a standalone makefile.
> >>
> >>I am not enthusiast of the idea of doing the opposite thing: starting 
> >>from another client's structure and putting inside all the other 
> >>features. I believe that this is more complicated and prone to bugs 
> >>everywhere.
> >>
> >>Fabrizio
> >>
> >>[log in to unmask] wrote:
> >>
> >>>Hi Pete,
> >>>
> >>>
> >>>
> >>>>Do you see a reason why we shouldn't just implement write() in Heinz's
> >>>>client and go from there?
> >>>
> >>>I see nothing wrong in using it as a starting point. However, we do have
> >>>some missing protocol pieces that need to be added (e.g., connection
> >>>multiplexing). I would dare say that Fabrizio should comment as well.
> >>>
> >>>
> >>>
> >>>>Ah, right. So what do we have to turn on to get the olbd's to allow
> >>>>(redirection for) writing? I see:
> >>>>
> >>>>olb.path s /store
> >>>>
> >>>>The doc on this is a bit terse. I guess that "s" actually means "rs" by
> >>>>default so I would need something like:
> >>>>
> >>>>olb.path w /whatever
> >>>>
> >>>>to allow me to write files to /kanga/whatever
> >>>
> >>>Almost right (see below). Terse, eh? You're always welcome to suggest
> >>>expansions.
> >>>
> >>>
> >>>
> >>>>? (And turn off the staging, which wouldn't be relevant in the case of
> >>>>the "output buffers", for example. In that case "whatever" would 
> >>>>actually
> >>>>be "store", but that is a detail.)
> >>>
> >>>Not quite. In fact, you really do need to say "ws" because, in fact, you
> >>>will be creating files. Temporally, it is difficult to figure wout 
> >>>whether
> >>>you are trying to update an existing file or create one from whole cloth.
> >>>So, you could get rid of "s" but then you would not be able to create any
> >>>new files. I guess I need to check what the xrootd is configured to do by
> >>>default (I know we decided this based on Objectivity years ago).
> >>>
> >>>Andy
> >



-------------------------------------------------------------------------
Peter Elmer     E-mail: [log in to unmask]      Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-------------------------------------------------------------------------