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
>
>
Received on 2006-06-16Z16:17:45