Hi All, there is a regular telcon today at 14:00 UTC, 15:00 GMT, 10:00 ET Dialin numbers: UK - 0870 240 7821 USA (east) - 718 354 1169 Germany - 06950070811 International: +442078193600 Passcode: 14712935# cheers, neil 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@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