ByteIO - GGF14 

Note Taker: Andre Merzky

  - agenda bashing (Tom): 
    - relate to other groups

  - Audience:
    - initial comment: variety of 'sources' is challenging

  - Andre:
    - security in scope?
      - not explicit, but for transport layer
      - soap extensions for sec. are considered

  - Osamu Tatebe: 
    - what about writing?
      - charter includes that now
    - discussion about writing?
      - bytio adresses what other WGs need
      - write seems in demand
      - as long as it's simple, write is symmetric to read, so why not
        include it?
    - was not included at BoF, but why now?
      - have not been sure if it complicates things then, but now we
        are sure it does not
      - consistency is the hard part obviously
      - legion and avaki can deal with that (move responsibility to
        client)
      - avaki: advisory locks work well
      - server side and client side do not need to mach 100%, can be
        still a coherent consistency model
    - later comment: use cases should incorporate write cases...
      
  - Andre:
    - saga use cases considered?
      - yes, will continue to do so
    - include pseudo code section in use case template

  - UC-1:
    - Andre: relation/added value to GridFTP?
      - in contact, that is what GrdiFTP would do if going to higher
        level

  - UC-2:
    - Andre: does stream include push model?
      - no
    - Tom: RNS?
      - Resource Namespace Service - mapper to grid-namespace

  - stream access:
    - Audience: if you don;t have session, you need auth, init etc.
      every time -> performance?
      - implementation detail
    - Security overhead w/o handle?
      - network overhead is bigger
      - audience disagrees
      - caching helps, also for sec.
      - clarify: don't expect client API sessionless!
      - final: can be either or, lets see what experience shows
      - later comment: we are not trying to solve all problems!

  - Async query:
    - Andre: looks like async GridRPC data handle

  - readv  etc...
    - see discussion on SAGA-RG mailing list!

  - is there QoS?
    - out of scope!

  - Audience:
    - truncate?
      - is covered by truncateAppend with 0 bytes append
    - isn't it cleaner to separate?
      - seems useful to have both atomically unified, no need for
        separation visible right now

  - Andre: 
    - what are the transfer modes?
      - semantically defined in the group!

  - Andre:
    - open/read/close/open/read -> reads same data twice?
      - whatever the implementation thinks as starting point is read.

  - Audience:
    - Factory: seems clean for specifying open etc. cleanly
      - we want it flexible, factory makes tht more difficult
        (stream/file plymorphism)
    - example for polymorphism stream/file?
      - hdd
    - Thilo: you have random access, so you can define stream as one
      of the ordered access modes on the random access
      - right, but all that makes hard to come up with a  good factory
        pattern.
      - open can be semantically complex

  - Osamu:
    - performance: can be inefficient!
      - right.  
      - Related: can caching be applied generically?
      - Related: can every WS be used inefficiently?  -> yes.  Often
        its the easy way.  If you don;t care, then its fine.  If I do
        care, than cache!
      - why stream AND file?
        - stream REQUIRES state (more or less)
    - are there implicit perfoprmance issues for long distance access?
      if yes, do separate interface!
    - Audience: does interface IMPLY performance hit?  If yes, you
      NEED open and session!
      
      [missed parts of the discussion]
      
    - session opens problems in interop with other WS groups.
    - option is to combine seek/write and seek/read
      - gives problems with return value
      - long seek return gives current position
      - seek/read gives positoin NOT back

      [missed parts of the discussion]
      
      - why not getPosition?
        - contradicts WSRF profile
      
  - Audience:
    - byteio:num-bytes should be long
      - it's not accidentically int :-P
      - will never be used!
    - people will want it anyway
      - let's see if they will (public comment)

  - Audience:
    - everything about whoami etc goes into envelope?
      - addressed in the profiles, so external to this group

  - Andre:
    - implemetation already published?
      - not yet
      - will publish, and cross post to SAGA list

  
-- EOS