OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

asap message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [asap] issues - GetXXXProperites

Title: RE: [asap] issues - GetXXXProperites

Issue: GetProperties vs. GetInstanceProperties & GetFactoryProperties.

I don't understand the problem.  We are defining "resources".  Each of these resources have properties, and the GetProperties returns them.  Properties themselves have names, and there is an implicit assumption that property names uniquely match a property value.

What if every "kind" of resource had different methods for getting properties?  What about GetActivtyProperties, GetPOProperties, GetAccountApplicationProperties?  This trend is clearly not supportable.

A Factory is a resource, and Instances are resources.  Remind me: why do we need two different operations to get properties?


Keith D Swenson, kswenson@us.fujitsu.com
Fujitsu Software Corporation
1250 E. Arques Avenue, Sunnyvale, CA 94085
(408) 746-6276   mobile: (408) 859-1005

-----Original Message-----
From: John Fuller [mailto:jfuller@wernervas.com]
Sent: Tuesday, March 30, 2004 12:33 PM
Subject: [asap] issues

                Methods like GetInstanceProperties and GetFactoryProperties
                would allow us to retrieve the particular properties we may be
                interested in and allow us to dispatch off the method.

                If the properties were really intended to be implemented as a set instead,
                WS Resource Properties provides ways to do this:
                for a single property, a list of qnames representing the properties,
                or a properties conforming to a query.
                While this would be nice to support, it would take some time to implement.
                An advantage of only returning some properties is if context data or history
                are huge and not necessary for a client who just wants the current state.

                Since context data can be arbitrarily complex, implementers may struggle
                with storage, retrieval, and management using a generic engine.
                Client implementers have sort of balked when introduced to this kind of type.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]