[byteio-wg] Minutes from telcon today + issues list

neil p chue hong N.ChueHong at epcc.ed.ac.uk
Tue Oct 18 10:45:48 CDT 2005


ByteIO 18/10/2005
-----------------
Attending:
Mark Morgan (UVa)
Neil Chue Hong (EPCC)
Michel Drescher (FLE)

We discussed the issues arising from the discussion at GGF15, and assigned
them.
Mark will take a pass at the documents and then pass on to Neil for
completion and submission.

Mark has been finishing up an implementation and has written a simple ftp
interface for it, allowing you to copy Windows Explorer to it transferring
using the ByteIO specification.
If possible we'd like more ByteIO implementations and do interop
demostrations in  Dec/Jan.
Michel is embarking on an implementation using parallel HTTP based on
Unicore in a few weeks time. Implementations should be easy but interop will
be harder between MS Webservices and Globus Web Services etc. 

ACTION Come up with an interop scenario we can all work towards.

We will examine the possibility of having an interop meeting at the next
OGSA F2F in January 2006.

ISSUES LIST

ISSUE: "I" in the "IRandomByteIO" and "IStreamableByteIO" names is confusing
DISCUSSION: It comes from a naming convention for interfaces from Java
programming but may be misleading as it could have meant "Immediate" as
opposed to  "deferred", also it is clear that interfaces are being specified
SOLUTION: Delete the I from the interface names

ISSUE: Why is stride unsigned for the RandomByte interface? 
DISCUSSION: You may want to stride backwards... No particular reason, happy
to change.
SOLUTION: Change stride to be signed

ISSUE: Why is there an offset in the Streamable seekRead / seekWrite?
DISCUSSION: This is fine (and useful) for implementations where such an
offset can be provided. Where implementations cannot provide an offsetable
read/write, an  appropriate fault should be returned.
SOLUTION: Check consistency with listed faults and determine if fault is
required

ISSUE: Why do you not provide for a method to read from negative offsets in
the RandomByte interface (i.e. read from the end of the file)?
DISCUSSION: We've assumed that the client knows where they wants to seek in
the file and if the client wants this functionality that it knows what the
total file size is and can calculate appropriate the offset. Our model for
RandomByte assumes that the web service is simple and client is complex.
SOLUTION: Check that this is made clear in spec

ISSUE: Does seekRead(Streamable) ensure the number of bytes requested are
returned?
DISCUSSION: No, the read requests do NOT ensure the requested number of
bytes are returned
SOLUTION: Check this is clear in spec

ISSUE: Provide an example of how to efficiently read from the end from a log
file that is permanently appended using ByteIO interface
SOLUTION: add to the use cases document? or provide technical solution?

ISSUE: Change the minOccurs of Modification Time and Access Time properties
to "0" for RandomByte interface
SOLUTION: As per issue

ISSUE: Clarify timestamp remarks with respect to the clock synchronisation
issues of hosts when creating a resource (i.e. file)
SOLUTION: As per issue


ISSUE: Change ModificationTime and AccessTime properties for RandomByte
interface from SHOULD to MAY
SOLUTION: As per issue

ISSUE: Add a boolean Seekable property to Streamable interface
SOLUTION: As per issue

ISSUE: A clarification about concurrency in ByteIO is required (lifetime
management)
SOLUTION: Add a note saying that this is out of scope and up to
implementors. It is a similar example to two processes sharing the same
stream.

ISSUE: Documentation headers need to be corrected
SOLUTION: Follow GGF document guidelines

ISSUE: ch 1.3 Namespaces should be made consistent with GGF namespace
proposal
DISCUSSION:   The URL to the document is
https://forge.gridforum.org/tracker/? 
func=detail&aid=1570&group_id=90&atid=414
   Based on that, the namespaces for ByteIO in this chapter would be:
     http://schemas.ggf.org/byteio/2005/10/byteio
     http://schemas.ggf.org/byteio/2005/10/random-access
     http://schemas.ggf.org/byteio/2005/10/streamable-access
SOLUTION: Update namespaces to use GGF namespace proposal

ISSUE: ch. 2.1 port types should be made consistent with GGF namespace
proposal
DISCUSSION: The different documented transfer mechanisms would be (according
to the  namespaces document:
     http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple
     http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/dime
     http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/mtom
   Further references in the document (especially the examples!) meed to  be
changed then, too
SOLUTION: Update to use GGF namespace proposal

ISSUE: ch. 2.1 Port types, third paragraph
DISCUSSION: should clarify requirement
   Original:
   "In order to support [...] will include the following XML element as a
bulk transfer payload[1]:"
   Suggested change:
   "In order to support [...] MUST include the following XML element as a
bulk transfer payload[1]:"
SOLUTION: update as suggested

ISSUE: Confusion over bulk-transfer-information / transfer-information
elements
DISCUSSION:
   Some examples and XML / SOAP snippets and documents have one in
common: The specification defines a "byteio:bulk-transfer-information"
element that will (MUST? see above) be included in every message dealing
with bulk data transfer.
   A number of examples so far use "byteio:transfer-information" instead.
This is possibly a copy/paste error.
Actually, the former represented a schema type, the latter elements of that
schema type in messages so the difference in name is okay. However to avoid
confusion we should rename the type from bulk-transfer-information to
transfer-information-type.
SOLUTION: Change bulk-transfer-information to transfer-information-type and
check for consistency.


-- 
Neil P Chue Hong            | T: [+44] (0)131 650 5957
Project Manager, EPCC       | F: [+44] (0)131 650 6555
Rm 2409, JCMB, Mayfield Rd. | E: N.ChueHong at epcc.ed.ac.uk
Edinburgh, EH9 3JZ, UK      | W: http://www.epcc.ed.ac.uk      

BT MeetMe: http://tinyurl.com/8mwhd - Code: 14712935#  

  "A film is like a battleground. It's love, hate, action,
   violence, death - in a word, emotion." - Sam Fuller






More information about the byteio-wg mailing list