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-337523Received on 2006-06-16Z16:40:08