Yes to introducing CreateTempNode as you have written it with these caveats:
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-337523Received on 2006-06-16Z12:51:13