[byteio-wg] Minutes from telcon today + issues list
Michel Drescher
Michel.Drescher at uk.fujitsu.com
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
>
>
>
More information about the byteio-wg
mailing list