From patrick.dowler at nrc-cnrc.gc.ca Wed Nov 2 13:16:34 2011 From: patrick.dowler at nrc-cnrc.gc.ca (Patrick Dowler) Date: Wed, 2 Nov 2011 13:16:34 -0700 Subject: ivo://ivoa.net/vospace/core#date property Message-ID: <201111021316.34846.patrick.dowler@nrc-cnrc.gc.ca> At the Pune interop I presented our prototype work called cadcVOFS: a FUSE filesystem driver that allows one to mount a vospace container as a network filesystem. The filesystem interface is quite concerned with timestamps and the one standard timestamp-ish property is not really sufficient. Plus it is fairly vaguely defined, which has pros and cons. I proposed that we could standardise 3 properties with more explicit meanings. ivo://ivoa.net/vospace/core#mtime == data modification time ivo://ivoa.net/vospace/core#ctime == status change (aka metadata modification) ivo://ivoa.net/vospace/core#btime == initial creation time We will proceed to implement this in our own vospace in order to support cadcVOFS (and could use custom property URIs for that), but it seems good to make them core properties so users can mount other vospace containers as well. So far, users really like the idea but we struggle with efficiency issues and this helps resolve some of them. PS-don't check out and try to use the code; it is a crude prototype only :-) -- Patrick Dowler Tel/T?l: (250) 363-0044 Canadian Astronomy Data Centre National Research Council Canada 5071 West Saanich Road Victoria, BC V9E 2M7 Centre canadien de donnees astronomiques Conseil national de recherches Canada 5071, chemin West Saanich Victoria (C.-B.) V9E 2M7 From dtody at nrao.edu Thu Nov 3 09:12:05 2011 From: dtody at nrao.edu (Douglas Tody) Date: Thu, 3 Nov 2011 10:12:05 -0600 (MDT) Subject: ivo://ivoa.net/vospace/core#date property In-Reply-To: <201111021316.34846.patrick.dowler@nrc-cnrc.gc.ca> References: <201111021316.34846.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: I think it is a very good idea to support the standard file model in VOSpace. VOFS is an interesting approach for integrating VOSpace into the desktop. - Doug On Wed, 2 Nov 2011, Patrick Dowler wrote: > > At the Pune interop I presented our prototype work called cadcVOFS: a FUSE > filesystem driver that allows one to mount a vospace container as a network > filesystem. The filesystem interface is quite concerned with timestamps and the > one standard timestamp-ish property is not really sufficient. Plus it is fairly > vaguely defined, which has pros and cons. > > I proposed that we could standardise 3 properties with more explicit meanings. > > ivo://ivoa.net/vospace/core#mtime == data modification time > ivo://ivoa.net/vospace/core#ctime == status change (aka metadata modification) > ivo://ivoa.net/vospace/core#btime == initial creation time > > We will proceed to implement this in our own vospace in order to support > cadcVOFS (and could use custom property URIs for that), but it seems good to > make them core properties so users can mount other vospace containers as well. > So far, users really like the idea but we struggle with efficiency issues and > this helps resolve some of them. > > PS-don't check out and try to use the code; it is a crude prototype only :-) > > -- > > Patrick Dowler > Tel/T?l: (250) 363-0044 > Canadian Astronomy Data Centre > National Research Council Canada > 5071 West Saanich Road > Victoria, BC V9E 2M7 > > Centre canadien de donnees astronomiques > Conseil national de recherches Canada > 5071, chemin West Saanich > Victoria (C.-B.) V9E 2M7 > From patrick.dowler at nrc-cnrc.gc.ca Wed Nov 16 15:38:05 2011 From: patrick.dowler at nrc-cnrc.gc.ca (Patrick Dowler) Date: Wed, 16 Nov 2011 15:38:05 -0800 Subject: VOSpace 2.0 issues In-Reply-To: <3B2F21ED-BD96-425D-917E-656B3637BE06@cacr.caltech.edu> References: <3B2F21ED-BD96-425D-917E-656B3637BE06@cacr.caltech.edu> Message-ID: <201111161538.05858.patrick.dowler@nrc-cnrc.gc.ca> On 2011-10-10 13:09:10 Matthew Graham wrote: > (3) Faults in deleteNode > > By definition, the parent of the node to be deleted should exist and be a > ContainerNode. However, it is not directly specified as the node to be > deleted but implied. I'm not sure I understand the last sentence above... > If it does not exist or is not a ContainerNode then > that reflects an internal inconsistency in the VOSpace service. A 500 is > therefore a more appropriate error than a 404 in this context. Similar > arguments apply to the LinkNode as parent. I'm still not getting it. If a client does a DELETE /vospace/nodes/A/B/C then C is the node to delete. If C does not exist: 404 NodeNotFound (ok). If A or B do not exist, why not 404 ContainerNotFound? It is not an internal error at all that A and B don't exist... the client just made up the path and did a delete and the path does not exist. If B is a LinkNode, I can see not wanting to allow someone to delete things underneath it (and *not* doing a recursive delete if someone tries to delete the link node itself), but assuming one can make a LinkNode -> ContainerNode, such a request does not imply a server-side inconsistent state, just an illegal client request (which IMO should be 400 LinkFound). -- Patrick Dowler Tel/T?l: (250) 363-0044 Canadian Astronomy Data Centre National Research Council Canada 5071 West Saanich Road Victoria, BC V9E 2M7 Centre canadien de donnees astronomiques Conseil national de recherches Canada 5071, chemin West Saanich Victoria (C.-B.) V9E 2M7