[ogsa-naming-wg] [GFS-WG] RNS 1.1 v3

[Osamu Tatebe]

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