On 20.06.2006, at 11:29, Matthew Graham wrote:
> Hi,
>
> I do not think that this is what Dave is suggesting: for the import
> methods, he has: "if the target node does not exist, then the
> import methods will create a new node and import the data into
> that." I think that the same behaviour is implied for copyNode and
> that it just has failed to be stated explicitly.
yes - you are right - I miss-read the logic of the NOT on the copyNode operation (Dave was actually referring to the "overwrite policy"...), and mis-understood "does not create new names" to mean does not create new nodes -
> Cheers,
>
> Matthew
>
> Paul Harrison wrote:
>
>> I should have chosen my words more carefully - I did not mean any
>> formal "overloading" in the wsdl sense, but simply having a
>> xsd:choice in the parameter set, though I can see that this is
>> probably best avoided as I can see that it might not map too well
>> onto the "pseudo rpc" that .NET transforms the doc/literal/
>> wrapped into when presented to the programmer. It would still be
>> very useful if someone could take the wsdl and run it through
>> a .Net code generator.
>>
>> So yes go with another method CreateUniqueNode
>>
>> However, I am still unhappy about the use of CreateNode in
>> VOSpace 1.0 - it seems to be leading Dave to what to produce
>> complicated semantics for the data manipulation methods in his 5
>> point proposal in the start of this thread. He has it illegal for
>> the target URI of these operations *NOT* to point to an existing
>> node - this means that createNode has to be executed before a
>> copyNode for instance - the unix analogy is that you have to do a
>> "touch" before every "cp" - this seems perverse to say the least.
>> I think that it would be far better if the opposite behaviour was
>> the default - i.e. the data manipulation operations simply create
>> the target node if it does not exist. We can set the "overwrite
>> policy" to "don't overwrite - throw fault" by default with an
>> optional flag to force the overwrite (permissions allowing of
>> course).
>>
>> Paul.
>>
>> On 20.06.2006, at 09:31, Guy Rixon wrote:
>>
>>> On Tue, 20 Jun 2006, Paul Harrison wrote:
>>>
>>>> Cannot the functionality be simply overloaded on createNode?
>>>
>>>
>>> The idea was to avoid overloading operation names. There's a
>>> rumor that
>>> overloading doesn't work consistently with doc/literal/wrapped.
>>>
>>>>
>>>> On 16.06.2006, at 16:39, Guy Rixon wrote:
>>>>
>>>>> CreateUniqueNode is fine by me.
>>>>>
>>>>> On Fri, 16 Jun 2006, Dave Morris wrote:
>>>>>
>>>>>> How about calling it CreateUniqueNode ?
>>>>>> Takes optional set of properties and returns a new DataNode
>>>>>> with a
>>>>>> unique name within the space.
>>>>>>
>>>>>> We can add a type parameter in VoSpace-2.x to allow this to
>>>>>> create
>>>>>> other
>>>>>> types of node, including containers.
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>> Guy Rixon wrote:
>>>>>>
>>>>>>> Yes to introducing CreateTempNode as you have written it with
>>>>>>> these caveats:
>>>>>>>
>>>>>>> 1. Is createTempNode the best name?
>>>>>>>
>>>>>>> 2. Spec needs language making it clear that the node is created
>>>>>>> with a
>>>>>>> guaranteed-unique name.
>>>>>>>
>>>>>>> 3. Any other special semantics that we need to write down?
>>>>>>>
>>>>>>> 4. Is it a special type of node? (I suggest it can't be,
>>>>>>> since we
>>>>>>> only really
>>>>>>> have data nodes at this stage.)
>>>>>>>
>>>>>>> 5. The name parameter on the basic createNode will become
>>>>>>> mandatory if we make
>>>>>>> this change.
>>>>>>>
>>>>>>> Given that the node is an ordinary data-node and doesn't have
>>>>>>> any
>>>>>>> temporary-file semantics (c.f. the POSIX temporary files that
>>>>>>> disappear when
>>>>>>> the creating process exists), I suggest that
>>>>>>> createAndNameNode is
>>>>>>> a better
>>>>>>> name than createTempNode.
>>>>>>>
>>>>>>> (BTW, when we extend this to VOSpace 2, I hope we'll allow
>>>>>>> creation of
>>>>>>> auto-named container-nodes as well. But let's not get side-
>>>>>>> tracked by that
>>>>>>> now.)
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Guy
>>>>>>>
>>>>>>> On Thu, 15 Jun 2006, Matthew Graham wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I accept Dave's suggestions.
>>>>>>>>
>>>>>>>> I also accept Guy's suggestion for a separate operation for
>>>>>>>> creating a
>>>>>>>> temporary node with a server-generated name and propose adding
>>>>>>>> this text
>>>>>>>> to the spec:
>>>>>>>>
>>>>>>>> createTempNode
>>>>>>>>
>>>>>>>> Creates a temporary node in a space. This method is used to
>>>>>>>> create a
>>>>>>>> temporary data node.
>>>>>>>>
>>>>>>>> Parameters: None
>>>>>>>>
>>>>>>>> Returns: A <node> element for the new node.
>>>>>>>>
>>>>>>>> Faults: The service may throw an OperationNotSupported
>>>>>>>> exception if it
>>>>>>>> does not support temporary nodes.
>>>>>>>> The service may throw an InternalFault
>>>>>>>> exception if an
>>>>>>>> operation fails.
>>>>>>>> The service may throw a PermissionDenied exception
>>>>>>>> if the
>>>>>>>> user does not have permissions to perform the operation.
>>>>>>>>
>>>>>>>> Questions:
>>>>>>>> - Should a properties structure be an optional parameter?
>>>>>>>> - A user can always make a temporary node permanent by renaming
>>>>>>>> it to
>>>>>>>> something more meaningful.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Matthew
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Guy Rixon wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Use case for server-generated names: when clients working in
>>>>>>>>> the same space
>>>>>>>>> want to generate temporary files with unique names. Java
>>>>>>>>> File.makeTempFile()
>>>>>>>>> and all that. If we support this, it might deserve its own
>>>>>>>>> operation with
>>>>>>>>> different parameters from createNode.
>>>>>>>>>
>>>>>>>>> On Thu, 15 Jun 2006, Dave Morris wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Paul Harrison wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 14.06.2006, at 14:01, Dave Morris wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> However, when creating a new node, it was agreed that the
>>>>>>>>>>>> client
>>>>>>>>>>>> would supply the name as a plain text string, and the
>>>>>>>>>>>> server
>>>>>>>>>>>> would
>>>>>>>>>>>> convert this into the URI encoded identifier.
>>>>>>>>>>>> This means that the server side code does the URI encoding,
>>>>>>>>>>>> making
>>>>>>>>>>>> it easier to verify that we get it right.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The operations that create a new node (CreateNode,
>>>>>>>>>>>> PushDataTo and
>>>>>>>>>>>> PullDataTo) take the name of the new node, not the
>>>>>>>>>>>> identifier.
>>>>>>>>>>>> This gives us a way of distinguishing between import
>>>>>>>>>>>> into an
>>>>>>>>>>>> existing node (node URI) and import into a new node (node
>>>>>>>>>>>> name).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> also I think that there was also the idea that the
>>>>>>>>>>> server would
>>>>>>>>>>> generate a name automatically so the URI could point to a
>>>>>>>>>>> container...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> The distinction still isn't as clear as I would like, but
>>>>>>>>>>>> that is
>>>>>>>>>>>> what is in the current document.
>>>>>>>>>>>> If we want to change this, then we will need to modify the
>>>>>>>>>>>> document.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> I think that the semantics of these operations are not still
>>>>>>>>>>> clear as
>>>>>>>>>>> currently implemented in the WSDL, and do need some work
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> I too was struggling with how to represent these multiple
>>>>>>>>>> parameters in
>>>>>>>>>> the experimental WSDL examples I posted last week.
>>>>>>>>>> If they are causing problems, do we want to look at these
>>>>>>>>>> again, and
>>>>>>>>>> possibly simplify them.
>>>>>>>>>>
>>>>>>>>>> ----
>>>>>>>>>>
>>>>>>>>>> Server generated identifiers :
>>>>>>>>>> The original reason for server generated identifiers dates
>>>>>>>>>> back to when
>>>>>>>>>> we had two separate namespaces, VOSpace with user defined
>>>>>>>>>> names, and
>>>>>>>>>> VOStore with server generated names.
>>>>>>>>>> The VOStore service needed to generate the names in order to
>>>>>>>>>> ensure that
>>>>>>>>>> they were unique within that service.
>>>>>>>>>>
>>>>>>>>>> Now that we have brought everything into one VOSpace
>>>>>>>>>> namespace, I don't
>>>>>>>>>> think we need the server generated names any more.
>>>>>>>>>> In which case, unless anyone has a compelling use case for
>>>>>>>>>> this, I vote
>>>>>>>>>> we drop it.
>>>>>>>>>>
>>>>>>>>>> ----
>>>>>>>>>>
>>>>>>>>>> Plain string name :
>>>>>>>>>> I proposed the idea of using the separate name and URI in
>>>>>>>>>> methods that
>>>>>>>>>> created nodes, primarily because I wanted to make the server
>>>>>>>>>> responsible
>>>>>>>>>> for encoding the URI correctly.
>>>>>>>>>> The client would just supply the name as a plain text string,
>>>>>>>>>> and the
>>>>>>>>>> server would encode it to create the full URI identifier.
>>>>>>>>>>
>>>>>>>>>> However, both of us have found problems trying to define a
>>>>>>>>>> clear and
>>>>>>>>>> concise WSDL that distinguishes between an import operation
>>>>>>>>>> that creates
>>>>>>>>>> a new node and one that imports data into an existing
>>>>>>>>>> node. In
>>>>>>>>>> which
>>>>>>>>>> case, it looks like having the separate name parameter for
>>>>>>>>>> creating a
>>>>>>>>>> new node is causing us more problems than it is worth.
>>>>>>>>>>
>>>>>>>>>> ----
>>>>>>>>>>
>>>>>>>>>> For VoSpace-1.0 I propose we drop both the server generated
>>>>>>>>>> names and
>>>>>>>>>> the separate name as string parameter.
>>>>>>>>>>
>>>>>>>>>> 1) CreateNode takes a mandatory target URI of the new node,
>>>>>>>>>> rather than
>>>>>>>>>> the optional string name.
>>>>>>>>>> The target URI cannot be null, and the service does not
>>>>>>>>>> automatically
>>>>>>>>>> generate new names.
>>>>>>>>>> It is up to the client to create and encode the target URI
>>>>>>>>>> correctly.
>>>>>>>>>> If the server receives an invalid URI, it throws an
>>>>>>>>>> Exception.
>>>>>>>>>>
>>>>>>>>>> 2) The two import methods also take a single URI parameter to
>>>>>>>>>> identify
>>>>>>>>>> the target node.
>>>>>>>>>> The target URI cannot be null, and the service does not
>>>>>>>>>> automatically
>>>>>>>>>> generate new names.
>>>>>>>>>> It is up to the client to create and encode the target URI
>>>>>>>>>> correctly.
>>>>>>>>>> If the server receives an invalid URI, it throws an
>>>>>>>>>> Exception.
>>>>>>>>>> If the target node already exists, then its contents will be
>>>>>>>>>> replaced by
>>>>>>>>>> the import.
>>>>>>>>>> If the target node does not exist, then the import methods
>>>>>>>>>> will create a
>>>>>>>>>> new node and import the data into that.
>>>>>>>>>> (this also implies that the <replace> flag is no longer
>>>>>>>>>> needed
>>>>>>>>>> either)
>>>>>>>>>>
>>>>>>>>>> Then, to make things symmetrical :
>>>>>>>>>>
>>>>>>>>>> 3) MoveNode takes two URIs, representing the source and
>>>>>>>>>> destination.
>>>>>>>>>> The source URI cannot be null and must point to an
>>>>>>>>>> existing node.
>>>>>>>>>> The destination URI cannot be null, and must NOT point to an
>>>>>>>>>> existing node.
>>>>>>>>>> If a node already exists with the destination URI, then the
>>>>>>>>>> method
>>>>>>>>>> throws a DuplicateNodeException.
>>>>>>>>>> It is up to the client to create and encode the destination
>>>>>>>>>> URI correctly.
>>>>>>>>>> If the server receives an invalid URI, it throws an
>>>>>>>>>> Exception.
>>>>>>>>>>
>>>>>>>>>> 4) CopyNode takes two URIs, representing the source and
>>>>>>>>>> destination.
>>>>>>>>>> The source URI cannot be null and must point to an
>>>>>>>>>> existing node.
>>>>>>>>>> The destination URI cannot be null, and must NOT point to an
>>>>>>>>>> existing node.
>>>>>>>>>> If a node already exists with the destination URI, then the
>>>>>>>>>> method
>>>>>>>>>> throws a DuplicateNodeException.
>>>>>>>>>> It is up to the client to create and encode the destination
>>>>>>>>>> URI correctly.
>>>>>>>>>> If the server receives an invalid URI, it throws an
>>>>>>>>>> Exception.
>>>>>>>>>>
>>>>>>>>>> To support client encoded URIs :
>>>>>>>>>>
>>>>>>>>>> 5) We need to add MalformedIdentifierException to the list of
>>>>>>>>>> exceptions
>>>>>>>>>> for all the methods that take URI parameters.
>>>>>>>>>>
>>>>>>>>>> Hopefully, this should make the service API and WSDL a lot
>>>>>>>>>> clearer.
>>>>>>>>>>
>>>>>>>>>> One caveat :
>>>>>>>>>> I would like to re-visit this when we look at v2.x, based on
>>>>>>>>>> what we
>>>>>>>>>> find using v1.0 in real applications.
>>>>>>>>>>
>>>>>>>>>> ----
>>>>>>>>>>
>>>>>>>>>> Matthew is right when he says that if we have any changes we
>>>>>>>>>> should be
>>>>>>>>>> discussing them in the document, and not the WSDL.
>>>>>>>>>> The WSDL should reflect the specification as defined in the
>>>>>>>>>> document,
>>>>>>>>>> presenting it in a machine readable form.
>>>>>>>>>>
>>>>>>>>>> So, based on the fact that both Paul and I have both found
>>>>>>>>>> problems in
>>>>>>>>>> creating a clear and concise WSDL to represent this part
>>>>>>>>>> of the
>>>>>>>>>> specification and that the original use cases for the extra
>>>>>>>>>> parameters
>>>>>>>>>> are either no longer valid or not worth the hassle.
>>>>>>>>>> I propose we make the above changes to the specification
>>>>>>>>>> document, and
>>>>>>>>>> then update the WSDL to match.
>>>>>>>>>>
>>>>>>>>>> Guy, Matthew, and Paul can you reply with 'accept' or
>>>>>>>>>> 'reject'
>>>>>>>>>> for the
>>>>>>>>>> five changes outlined above.
>>>>>>>>>> If everyone says yes, then we can update the document
>>>>>>>>>> tomorrow
>>>>>>>>>> and
>>>>>>>>>> publish it as v0.22.
>>>>>>>>>>
>>>>>>>>>> I know this is a bit formal and possibly OTT, but I suspect
>>>>>>>>>> that we will
>>>>>>>>>> be making quite a few changes like this over the next few
>>>>>>>>>> days.
>>>>>>>>>> Making specific requests for individual changes to the
>>>>>>>>>> document should
>>>>>>>>>> make it easier to keep track of everything.
>>>>>>>>>>
>>>>>>>>>> I know there is at least one case where I found the list of
>>>>>>>>>> exceptions
>>>>>>>>>> was wrong on one of the methods, but right now I can't
>>>>>>>>>> remember where it
>>>>>>>>>> was.
>>>>>>>>>> If I find it again I'll post another change request with the
>>>>>>>>>> details.
>>>>>>>>>>
>>>>>>>>>> There are also a couple of questions / suggestions I would
>>>>>>>>>> like to raise
>>>>>>>>>> regarding data types and formats.
>>>>>>>>>> I'll post another change request when I have worked out the
>>>>>>>>>> details.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dave
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Guy Rixon gtr-at-ast.cam.ac.uk
>>>>>>>>> Institute of Astronomy Tel:
>>>>>>>>> +44-1223-337542
>>>>>>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax:
>>>>>>>>> +44-1223-337523
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> Guy Rixon gtr-at-ast.cam.ac.uk
>>>>>>> Institute of Astronomy Tel:
>>>>>>> +44-1223-337542
>>>>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax:
>>>>>>> +44-1223-337523
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> Guy Rixon gtr-at-ast.cam.ac.uk
>>>>> Institute of Astronomy Tel: +44-1223-337542
>>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523
>>>>
>>>>
>>>
>>> Guy Rixon gtr-at-ast.cam.ac.uk
>>> Institute of Astronomy Tel: +44-1223-337542
>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523
>>
>>
Received on 2006-06-20Z12:16:59