1.0rc1 WSDL issues (create node params)

[Guy Rixon]

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