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