 |
 |
Hi Pete, 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? Fabrizio 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 > -------------------------------------------------------------------------