[ogsa-naming-wg] Slide material for the WG session
Osamu Tatebe
tatebe at cs.tsukuba.ac.jp
Wed Oct 14 14:41:22 CDT 2009
Hi all,
I uploaded the slide material I will use at tomorrow's
GFS-WG session that starts at 10:30am in DCH 307.
http://www.ogf.org/gf/event_schedule/?id=1748
This includes summary of the suggested updates for RNS-1.1,
and file catalog standardization including GFS-WG charter
discussion.
Please look at it, and give us comments during the session,
or by a mailing list.
Thanks,
Osamu
On Thu, 27 Aug 2009 10:12:02 +0900
Osamu Tatebe <tatebe at cs.tsukuba.ac.jp> wrote:
> Hi all,
>
> We would like to finalize the spec until the upcoming
> OGF27.
>
> Are there any response to the batch operation interface
> proposed by the Osaka University? At least, we agreed
> that the batch operation returned the vector of results
> to identify success or failure of each entry at OGF25.
>
> Moreover, we find another big problem about Resource
> Properties. In the current spec, createTime, accessTime
> and modificationTime are included in the Resource
> Properties. This means these cannot be obtained by the
> list operation. Instead, they are obtained by
> GetMuitipleResourceProperties for each entry, which
> requires a round trip for each entry. Especially
> 'ls -l' will be unacceptably slow from the distant
> location.
>
> Thanks,
> Osamu
>
> On Wed, 08 Jul 2009 02:41:33 +0900
> Hideo Matsuda <matsuda at ist.osaka-u.ac.jp> wrote:
>
> > Dear Erwin,
> >
> > As for the implementation of the batch operation, I sent Mark
> > our comments on the modification of RNS WSDL and XSD for making
> > it possible to detect which entries get faults.
> >
> > Sorry it was a personal communication.
> >
> > I re-send it to this mailing list.
> >
> > Best regards,
> >
> > Hideo Matsuda
> >
> > ------------------------------------------------------------------
> > Dear Mark,
> >
> > I apologize for my late response.
> >
> > Herein I enclosed our proposal of RNS WSDL and XSD corresponding
> > to the batch operation.
> >
> > New types "rns:EntryRequest" and "rns:EntryResponse"
> > are introduced to handle a list of entries and
> > entries with fault information (BaseFaultType), respectively.
> >
> > "add" operation does not return "RNSEntryExistsFault" but
> > return "EntryResponse" including fault information for each
> > entry.
> >
> > There exist some other minor changes.
> >
> > "add" request does not use "UserMetadataType" but use
> > "RNSMetadataType" to use "supports-rns" from the "add" request.
> >
> > Replace "entry-name" with "entry-names" in "LookupResponseType"
> > because it is a list of entry names.
> >
> > Best regards,
> >
> > Hideo Matsuda
> >
> >
> > > Dear GFS group,
> > >
> > > Are there any further comments to this document? I'd like to ask for
> > > group last call before sending out to public comments in two weeks from
> > > now.
> > >
> > > Cheers,
> > >
> > > -- Erwin
> > >
> > >
> > > Hideo Matsuda wrote:
> > >> Dear Mark,
> > >>
> > >> Thank you for updating RNS 1.1 specification.
> > >>
> > >> I have a question on the secification.
> > >> If multiple RNSEntry elements are put in an RNS add message
> > >> (namely, a batch operation) and some of them generate faults
> > >> (such as "WriteNotPermittedFault" or "RNSEntryExistsFault"),
> > >> how can we know which entries correspond to the faults?
> > >>
> > >> I guess one solution is that the fault messages also contain
> > >> the multiple RNSEntry elements that generate faults.
> > >>
> > >> Best regards,
> > >>
> > >> Hideo Matsuda
> > >>
> > >>> As promised, Andrew and I just finished updating the proposed RNS 1.1
> > >>> specification (and WS-Iterator specification) as discussed at the last
> > >>> OGF. As before, I would like to clarify that while the documents
> > >>> presented are in "official" OGF spec. format (if there is such a thing),
> > >>> that coincidence is merely for lack of a better format to use (i.e.,
> > >>> this is a draft recommendation to the groups, not a completed spec.).
> > >>>
> > >>> The changes in these documents were mostly to address
> > >>> concerns/thoughts/comments from the last OGF. Namely, a couple of
> > >>> changes to the wsdl/schema for typo's and some clarifying comments there
> > >>> as well. Further, the RNS port type has been changed to support batch
> > >>> operations on all operations except lookup (which already had a
> > >>> "batch-like" mode). Almost all changes to ws-iterator were cosmetic.
> > >>>
> > >>> There are three documents in question. The first two relate to RNS and
> > >>> are modelled after the ogsa byteio working groups attempt to address
> > >>> difficulties in OGSA BP renderings. These two documents consist of a
> > >>> rendering agnostic specification document generally describing RNS and
> > >>> RNS operations and giving example SOAP and XML for any operations which
> > >>> would be rendering agnostic. THe second document, the RNS-rendering
> > >>> document, renders the specification as an OGSA-WSRF-BP 1.0 adherent
> > >>> specification. The assumption of course being that as other renderings
> > >>> became available, they could likewise be used to produce alternate
> > >>> rendering compliant versions of the RNS 1.1 specification without
> > >>> invalidating the existing ones.
> > >>>
> > >>> The last document is for WS-iterator. As described before and detailed
> > >>> in the document itself, this specification is meant to provide a more
> > >>> "wsrf-like" interface to iteration then available specs like
> > >>> WS-Enumeration do. Because this is wsrf specific and meant only to
> > >>> replace alternately available methods of iteration to provide a more
> > >>> convenient abstraction for the WSRF-based RNS, this document is not
> > >>> split into two versions but rather consists of the entire specification
> > >>> and rendering (an OGSA-WSRF-BP 1.0 rendering) together.
> > >>>
> > >>> See you all at OGF!
> > >>>
> > >>> -Mark
> > >>>
> > >>>
> > >>> ------------------------------------------------------------------------
> --
> gfs-wg mailing list
> gfs-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/gfs-wg
More information about the ogsa-naming-wg
mailing list