Cannot the functionality be simply overloaded on createNode?
If we say that copyNode/moveNode and the import data methods simply do what they are told i.e. write to the data item that is pointed to by the vos: URL in their parameters, creating when necessary, then all "special" node creation could be done with createNode.
Not a crucial point, but for a v1.0 VOSpace it is rather difficult to see a use case for createNode (which really has more relevance for links/containers)....
On 16.06.2006, at 16:39, Guy Rixon wrote:
> 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-337523
Received on 2006-06-20Z09:13:12