Yes to CreateTempNode()
Yes to the optional properties parameter.
Thanks,
Dave
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
>>
>>
>>
Received on 2006-06-16Z00:12:19