[ogsa-naming-wg] Slide material for the WG session

[Osamu Tatebe]

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