OGSA Interim Meeting 12 - ByteIO================================  Location: Fujitsu Labs America, Sunnyvale, US  Date:     16 August 2005 (Day 2), morning* Summary of Actions:  ACTION: Michel and Mark to discuss client vs server transfer          protocol choice and whether there are any changes needed in          the ByteIO specification.  [Closed: to update spec)]  * Participants  Pete Ziu (Northrop Grumman)  Jay Unger (IBM)  Ellen Stokes (IBM)  Andreas Savva (Fujitsu)  Takuya Mori (NEC)  Mark Morgan (UVa)  Steve McGough (LeSC)  Fred Maciel (Hitachi)  Allen Luniewski (IBM)  Soonwook Hwang (NAREGI)  Donal Fellows (UoM)  Michel Drescher (Fujitsu)  Fred Brisard (CA)  Mike Behrens (R2AD, LLC)  Phone bridge:        Neil Chue Hong (EPCC)  Minutes: Michel Drescher, Andreas Savva* ByteIO Use Cases  Presentation:  https://forge.gridforum.org/projects/ogsa-wg/document/ByteIO_UseCases/en/1  Neil presents slides on ByteIO use cases for files   Neil presents slides on DAIS use cases  - Question Jay:        o Typical use case: most resources are flat files       o Many people now put their stuff into databases       o However, the applications are still designed for flat files       o And mostly CSV files are still needed  - Answer Mark:       o You would write a "filter ByteIO"  Neil continues to present the DAIS use cases  - ByteIO provides access to the data. It is not intended as a proxy    to streamable data.   Neil presents the Visualisation Service use case  - Fred asks:       o Are you aware of performance?  - Mark answers:       o ByteIO requires a base set of data transfers, that every         ByteIO implementor MUST support. It allows a choice of         protocol. At a minimum base64 encoding is required.  - Mike Behrens asks:       o Are or will these slides be on the GGF forge?       o Security?  - Mark answers:       o Yes, they will be uploaded       o Security is important       o If possible, use every security means available by OGSA for the control channel       o Security for the data channel is up to the implementation * ByteIO Interfaces Overview  Presentation:  https://forge.gridforum.org/projects/ogsa-wg/document/ByteIO_Overview/en/1  Mark presents details about the technical issues of ByteIO  - IRandomAccess       o Each operation is atomic           - No locking between operations. It can be implemented             separately if needed.       o Allows for strided reads or writes       o What happens to the 'holes' in write session in a file:           - The spec states it is undefined. But this is not a good             choice.             - Discussed alternatives and settled for:             - The original content if the file exists             - Zero/Undefined/implementation dependent if writing past               the end of the file. The expectation would be that a               separate operation would then 'fill in' these parts.       o truncAppend: to capture the typical case of truncating         to add data to a file  - IStreamableByteIO       o seekOrigin URI: it is an enum of 3 values.   Questions are taken  - Fred asks: Is there a means to get the attributes of a file?  - Mark answers:         o Yes, the document specifies means on how to access file attributes        o The rendering document specifies the means on how this          information is transferred (in fact, as ResourceProperties)  - Andreas asks: GidFTP will be just one of the mechanisms?  - Mark answers: yes  - Mike asks:        o Is ByteIO expected to be a lower level service than many other things we do?  - Mark answers:        o ByteIO a means to provide a simplistic access pattern to          possibly complex access patterns        o It also may be a foundation for an envisaged Grid File System  - Mike asks: Caching on the client side?  - Mark answers:         o Caching is a hot topic in OGSA        o Generally caching is a client side issue, not directly related to ByteIO  - Michel asks: Who chooses the protocol to be used for a transfer?  - Mark answers:         o In the current spec the server advertises the transfer           protocols it supports and the client chooses.   - Michel: It would also be useful to allow the other scenario of the    client offering a choice and the server choosing. There are cases    where this is useful.  ACTION: Michel and Mark to discuss client vs server transfer          protocol choice and whether there are any changes needed in          the ByteIO specification.  [Closed: to update spec)]* Overview of specifications    Refer to ByteIO gridforge site:  https://forge.gridforum.org/projects/byteio-wg  Mark shows highlights of the ByteIO documents  - There are two documents:    - First document describes the semantics and features required for a      rendering.    - Second document defines the rendering for the OGSA WSRF BP 1.0  - File creation is left out of scope right now.  - Andreas asks: Relation to RNS?  - Mark answers:        o No direct relation to RNS, except for CIFS and NFS use case,          where the file system structure becomes important. The          ByteIO and RNS specs could be combined to provide part of          this functionality.