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

Tue Oct 18 10:51:11 CDT 2005

Thanks Neil for the minutes.

I have no additions for them.

Cheers,
Michel

On 18 Oct 2005, at 16:45, neil p chue hong wrote:

>
> 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
>
>
>