Just trying to get my head around all the SugarSync concepts of
workspaces, shared folders, magic briefcases etc. (do users actually
understand this stuff?) Anyway, I'm trying to use SugarSync in the
same way that I might use a WebDAV (or Dropbox :-) interface - by
referring to files and folders by their 'human readable' path. For
example, I want to check the modified date on a file which the user
might consider as being in /My Desktop/My Project/plan.pdf - is this
possible without having to enumerate all the workspaces, collections
etc. I know that the URL to that file is persistent and if I know it
then I can use it - but at this point I haven't enumerated it?
So I've been plodding on with the API and now discovered that it will
happily create multiple copies of exactly the same filename. This is
mad. So now I have to enumerate an entire folder in order to determine
if a file exists already before attempting to upload an update to the
file - so I don't accidentally create a 'new' file. Does anyone know
of another way to check for the existence of a file without
enumerating the parent folder?
Thanks
On Jan 31, 11:15 am, Scotty <craig.mcfarlane.sc...@gmail.com> wrote:
> Just trying to get my head around all the SugarSync concepts of
> workspaces, shared folders, magic briefcases etc. (do users actually
> understand this stuff?) Anyway, I'm trying to use SugarSync in the
> same way that I might use a WebDAV (or Dropbox :-) interface - by
> referring to files and folders by their 'human readable' path. For
> example, I want to check the modified date on a file which the user
> might consider as being in /My Desktop/My Project/plan.pdf - is this
> possible without having to enumerate all the workspaces, collections
> etc. I know that the URL to that file is persistent and if I know it
> then I can use it - but at this point I haven't enumerated it?
Thanks for the note. We don't currently have a mechanism to check whether a file with a particular name exists - the fact that you can have multiple objects with the same name in a folder is actually a representation of the underlying data model, which supports this capability.
If you just want to construct a path for a particular file, you can probably start by walking upwards to the file's parent, grandparent, etc., until you get to the sync folder it's ultimately contained within. You can also find out which computers it's synced to in this fashion, though it may be associated with more than one.
>So I've been plodding on with the API and now discovered that it will >happily create multiple copies of exactly the same filename. This is >mad. So now I have to enumerate an entire folder in order to determine >if a file exists already before attempting to upload an update to the >file - so I don't accidentally create a 'new' file. Does anyone know >of another way to check for the existence of a file without >enumerating the parent folder?
>Thanks
>On Jan 31, 11:15 am, Scotty <craig.mcfarlane.sc...@gmail.com> wrote: >> Hi,
>> Just trying to get my head around all the SugarSync concepts of >> workspaces, shared folders, magic briefcases etc. (do users actually >> understand this stuff?) Anyway, I'm trying to use SugarSync in the >> same way that I might use a WebDAV (or Dropbox :-) interface - by >> referring to files and folders by their 'human readable' path. For >> example, I want to check the modified date on a file which the user >> might consider as being in /My Desktop/My Project/plan.pdf - is this >> possible without having to enumerate all the workspaces, collections >> etc. I know that the URL to that file is persistent and if I know it >> then I can use it - but at this point I haven't enumerated it?
Thanks for the reply Jim. So to confirm - if I want to upload a file
into a folder, the steps are as follows:
- Enumerate the entire folder to see if the file already exists.
- Whilst looking for the file I must cope with the possibility that
there may be multiple instances with the exact same name (I guess I
need to just pick one!?)
- If there is an existing file then I can PUT data into it (thus
creating a new version)
- If there isn't an existing file then I need to issue a CREATE
request and capture the resultant ID representing the file then PUT
data into that file ID.
Assuming that to be the case - you're making it very difficult to use
your API. In Dropbox, a single request will upload a file and even
create the necessary folder structure to support it and then return
the file attributes - quick and easy from both a developer and network
perspective. Even WebDAV makes this pretty easy. Hell, even Box.net is
easier than this - and their system is pretty obtuse.
Sorry - I'm ranting now - but your auth mechanism needs work too.
Currently you force me to store the users actual password (rather than
a token) and worse than that, I need cope with the fact that my
session times out after a very short time - requiring me to code up
the logic to recreate the session automatically (using the stored
password!!!) I'm not suggesting OAuth levels of security (which also
sucks from a user experience perspective) - but a simple token which
never times out would be better.
</RANT>
Do you have any published roadmap for the API? As it currently stands
it's not really going to work for me.
Thanks
On Jan 31, 7:46 pm, Jim Wong <jw...@sugarsync.com> wrote:
> Thanks for the note. We don't currently have a mechanism to check whether
> a file with a particular name exists - the fact that you can have multiple
> objects with the same name in a folder is actually a representation of the
> underlying data model, which supports this capability.
> If you just want to construct a path for a particular file, you can
> probably start by walking upwards to the file's parent, grandparent, etc.,
> until you get to the sync folder it's ultimately contained within. You
> can also find out which computers it's synced to in this fashion, though
> it may be associated with more than one.
> On 1/31/12 9:57 AM, "Scotty" <craig.mcfarlane.sc...@gmail.com> wrote:
> >So I've been plodding on with the API and now discovered that it will
> >happily create multiple copies of exactly the same filename. This is
> >mad. So now I have to enumerate an entire folder in order to determine
> >if a file exists already before attempting to upload an update to the
> >file - so I don't accidentally create a 'new' file. Does anyone know
> >of another way to check for the existence of a file without
> >enumerating the parent folder?
> >> Just trying to get my head around all the SugarSync concepts of
> >> workspaces, shared folders, magic briefcases etc. (do users actually
> >> understand this stuff?) Anyway, I'm trying to use SugarSync in the
> >> same way that I might use a WebDAV (or Dropbox :-) interface - by
> >> referring to files and folders by their 'human readable' path. For
> >> example, I want to check the modified date on a file which the user
> >> might consider as being in /My Desktop/My Project/plan.pdf - is this
> >> possible without having to enumerate all the workspaces, collections
> >> etc. I know that the URL to that file is persistent and if I know it
> >> then I can use it - but at this point I haven't enumerated it?
Thanks again for the note. The process is actually a bit simpler than that: if you don't have a URL for the file, just do a POST to create one and then a PUT to upload the associated file data. If you've previously uploaded a different version of the file, you can just do a PUT to upload the updated file data. If two files in the same directory end up having the same name, the system will sort things out, usually by creating a conflict file.
I can understand the appeal of the approach you describe, but it has disadvantages, as well - it's easier for applications (or different installations of the same application) to clobber each other's data, and it's a bit more sensitive to changes the user makes in terms of file system structure. Of course, no approach is perfect, and we're always thinking about ways to improve ours.
Authentication is absolutely something that's on our mind. We expect to eliminate the need for applications to store user's passwords in the not-too-distant future.
>Thanks for the reply Jim. So to confirm - if I want to upload a file >into a folder, the steps are as follows:
>- Enumerate the entire folder to see if the file already exists. >- Whilst looking for the file I must cope with the possibility that >there may be multiple instances with the exact same name (I guess I >need to just pick one!?) >- If there is an existing file then I can PUT data into it (thus >creating a new version) >- If there isn't an existing file then I need to issue a CREATE >request and capture the resultant ID representing the file then PUT >data into that file ID.
>Assuming that to be the case - you're making it very difficult to use >your API. In Dropbox, a single request will upload a file and even >create the necessary folder structure to support it and then return >the file attributes - quick and easy from both a developer and network >perspective. Even WebDAV makes this pretty easy. Hell, even Box.net is >easier than this - and their system is pretty obtuse.
>Sorry - I'm ranting now - but your auth mechanism needs work too. >Currently you force me to store the users actual password (rather than >a token) and worse than that, I need cope with the fact that my >session times out after a very short time - requiring me to code up >the logic to recreate the session automatically (using the stored >password!!!) I'm not suggesting OAuth levels of security (which also >sucks from a user experience perspective) - but a simple token which >never times out would be better.
></RANT>
>Do you have any published roadmap for the API? As it currently stands >it's not really going to work for me.
>Thanks
>On Jan 31, 7:46 pm, Jim Wong <jw...@sugarsync.com> wrote: >> Thanks for the note. We don't currently have a mechanism to check >>whether >> a file with a particular name exists - the fact that you can have >>multiple >> objects with the same name in a folder is actually a representation of >>the >> underlying data model, which supports this capability.
>> If you just want to construct a path for a particular file, you can >> probably start by walking upwards to the file's parent, grandparent, >>etc., >> until you get to the sync folder it's ultimately contained within. You >> can also find out which computers it's synced to in this fashion, though >> it may be associated with more than one.
>> On 1/31/12 9:57 AM, "Scotty" <craig.mcfarlane.sc...@gmail.com> wrote:
>> >So I've been plodding on with the API and now discovered that it will >> >happily create multiple copies of exactly the same filename. This is >> >mad. So now I have to enumerate an entire folder in order to determine >> >if a file exists already before attempting to upload an update to the >> >file - so I don't accidentally create a 'new' file. Does anyone know >> >of another way to check for the existence of a file without >> >enumerating the parent folder?
>> >> Just trying to get my head around all the SugarSync concepts of >> >> workspaces, shared folders, magic briefcases etc. (do users actually >> >> understand this stuff?) Anyway, I'm trying to use SugarSync in the >> >> same way that I might use a WebDAV (or Dropbox :-) interface - by >> >> referring to files and folders by their 'human readable' path. For >> >> example, I want to check the modified date on a file which the user >> >> might consider as being in /My Desktop/My Project/plan.pdf - is this >> >> possible without having to enumerate all the workspaces, collections >> >> etc. I know that the URL to that file is persistent and if I know it >> >> then I can use it - but at this point I haven't enumerated it?
Not sure how it is simpler than I describe? In my tests it just
creates multiple files with exactly the same name when I POST a create
request. I haven't seen a 'conflict file' - and even if there were
one, how would I know about it - without enumerating the entire folder
after each POST/create call?
To my mind, you guys need a 'Get File/Folder Attributes' call which
ideally takes a proper file path (as understood by users) - or failing
that, the containing folder URL and file/folder NAME.
Even better would be a utility function which maps 'file/folder paths'
to your internal URL id scheme.
Regarding the password thing - this is easy to fix. Make the token so
that it doesn't expire (unless the user chooses to invalidate it.) If
you plan to jump on the OAuth bandwagon then you should consider the
mobile app use case - which is a truly awful user experience if forced
to switch to a browser then back to the app.
On Feb 6, 7:00 am, Jim Wong <jw...@sugarsync.com> wrote:
> Thanks again for the note. The process is actually a bit simpler than
> that: if you don't have a URL for the file, just do a POST to create one
> and then a PUT to upload the associated file data. If you've previously
> uploaded a different version of the file, you can just do a PUT to upload
> the updated file data. If two files in the same directory end up having
> the same name, the system will sort things out, usually by creating a
> conflict file.
> I can understand the appeal of the approach you describe, but it has
> disadvantages, as well - it's easier for applications (or different
> installations of the same application) to clobber each other's data, and
> it's a bit more sensitive to changes the user makes in terms of file
> system structure. Of course, no approach is perfect, and we're always
> thinking about ways to improve ours.
> Authentication is absolutely something that's on our mind. We expect to
> eliminate the need for applications to store user's passwords in the
> not-too-distant future.
> On 1/31/12 1:09 PM, "Scotty" <craig.mcfarlane.sc...@gmail.com> wrote:
> >Thanks for the reply Jim. So to confirm - if I want to upload a file
> >into a folder, the steps are as follows:
> >- Enumerate the entire folder to see if the file already exists.
> >- Whilst looking for the file I must cope with the possibility that
> >there may be multiple instances with the exact same name (I guess I
> >need to just pick one!?)
> >- If there is an existing file then I can PUT data into it (thus
> >creating a new version)
> >- If there isn't an existing file then I need to issue a CREATE
> >request and capture the resultant ID representing the file then PUT
> >data into that file ID.
> >Assuming that to be the case - you're making it very difficult to use
> >your API. In Dropbox, a single request will upload a file and even
> >create the necessary folder structure to support it and then return
> >the file attributes - quick and easy from both a developer and network
> >perspective. Even WebDAV makes this pretty easy. Hell, even Box.net is
> >easier than this - and their system is pretty obtuse.
> >Sorry - I'm ranting now - but your auth mechanism needs work too.
> >Currently you force me to store the users actual password (rather than
> >a token) and worse than that, I need cope with the fact that my
> >session times out after a very short time - requiring me to code up
> >the logic to recreate the session automatically (using the stored
> >password!!!) I'm not suggesting OAuth levels of security (which also
> >sucks from a user experience perspective) - but a simple token which
> >never times out would be better.
> ></RANT>
> >Do you have any published roadmap for the API? As it currently stands
> >it's not really going to work for me.
> >Thanks
> >On Jan 31, 7:46 pm, Jim Wong <jw...@sugarsync.com> wrote:
> >> Thanks for the note. We don't currently have a mechanism to check
> >>whether
> >> a file with a particular name exists - the fact that you can have
> >>multiple
> >> objects with the same name in a folder is actually a representation of
> >>the
> >> underlying data model, which supports this capability.
> >> If you just want to construct a path for a particular file, you can
> >> probably start by walking upwards to the file's parent, grandparent,
> >>etc.,
> >> until you get to the sync folder it's ultimately contained within. You
> >> can also find out which computers it's synced to in this fashion, though
> >> it may be associated with more than one.
> >> Let us know if you have any further questions.
> >> On 1/31/12 9:57 AM, "Scotty" <craig.mcfarlane.sc...@gmail.com> wrote:
> >> >So I've been plodding on with the API and now discovered that it will
> >> >happily create multiple copies of exactly the same filename. This is
> >> >mad. So now I have to enumerate an entire folder in order to determine
> >> >if a file exists already before attempting to upload an update to the
> >> >file - so I don't accidentally create a 'new' file. Does anyone know
> >> >of another way to check for the existence of a file without
> >> >enumerating the parent folder?
> >> >> Just trying to get my head around all the SugarSync concepts of
> >> >> workspaces, shared folders, magic briefcases etc. (do users actually
> >> >> understand this stuff?) Anyway, I'm trying to use SugarSync in the
> >> >> same way that I might use a WebDAV (or Dropbox :-) interface - by
> >> >> referring to files and folders by their 'human readable' path. For
> >> >> example, I want to check the modified date on a file which the user
> >> >> might consider as being in /My Desktop/My Project/plan.pdf - is this
> >> >> possible without having to enumerate all the workspaces, collections
> >> >> etc. I know that the URL to that file is persistent and if I know it
> >> >> then I can use it - but at this point I haven't enumerated it?
>Not sure how it is simpler than I describe? In my tests it just >creates multiple files with exactly the same name when I POST a create >request. I haven't seen a 'conflict file' - and even if there were >one, how would I know about it - without enumerating the entire folder >after each POST/create call?
>To my mind, you guys need a 'Get File/Folder Attributes' call which >ideally takes a proper file path (as understood by users) - or failing >that, the containing folder URL and file/folder NAME.
>Even better would be a utility function which maps 'file/folder paths' >to your internal URL id scheme.
>Regarding the password thing - this is easy to fix. Make the token so >that it doesn't expire (unless the user chooses to invalidate it.) If >you plan to jump on the OAuth bandwagon then you should consider the >mobile app use case - which is a truly awful user experience if forced >to switch to a browser then back to the app.
>On Feb 6, 7:00 am, Jim Wong <jw...@sugarsync.com> wrote: >> Thanks again for the note. The process is actually a bit simpler than >> that: if you don't have a URL for the file, just do a POST to create one >> and then a PUT to upload the associated file data. If you've previously >> uploaded a different version of the file, you can just do a PUT to >>upload >> the updated file data. If two files in the same directory end up having >> the same name, the system will sort things out, usually by creating a >> conflict file.
>> I can understand the appeal of the approach you describe, but it has >> disadvantages, as well - it's easier for applications (or different >> installations of the same application) to clobber each other's data, and >> it's a bit more sensitive to changes the user makes in terms of file >> system structure. Of course, no approach is perfect, and we're always >> thinking about ways to improve ours.
>> Authentication is absolutely something that's on our mind. We expect to >> eliminate the need for applications to store user's passwords in the >> not-too-distant future.
>> On 1/31/12 1:09 PM, "Scotty" <craig.mcfarlane.sc...@gmail.com> wrote:
>> >Thanks for the reply Jim. So to confirm - if I want to upload a file >> >into a folder, the steps are as follows:
>> >- Enumerate the entire folder to see if the file already exists. >> >- Whilst looking for the file I must cope with the possibility that >> >there may be multiple instances with the exact same name (I guess I >> >need to just pick one!?) >> >- If there is an existing file then I can PUT data into it (thus >> >creating a new version) >> >- If there isn't an existing file then I need to issue a CREATE >> >request and capture the resultant ID representing the file then PUT >> >data into that file ID.
>> >Assuming that to be the case - you're making it very difficult to use >> >your API. In Dropbox, a single request will upload a file and even >> >create the necessary folder structure to support it and then return >> >the file attributes - quick and easy from both a developer and network >> >perspective. Even WebDAV makes this pretty easy. Hell, even Box.net is >> >easier than this - and their system is pretty obtuse.
>> >Sorry - I'm ranting now - but your auth mechanism needs work too. >> >Currently you force me to store the users actual password (rather than >> >a token) and worse than that, I need cope with the fact that my >> >session times out after a very short time - requiring me to code up >> >the logic to recreate the session automatically (using the stored >> >password!!!) I'm not suggesting OAuth levels of security (which also >> >sucks from a user experience perspective) - but a simple token which >> >never times out would be better.
>> ></RANT>
>> >Do you have any published roadmap for the API? As it currently stands >> >it's not really going to work for me.
>> >Thanks
>> >On Jan 31, 7:46 pm, Jim Wong <jw...@sugarsync.com> wrote: >> >> Thanks for the note. We don't currently have a mechanism to check >> >>whether >> >> a file with a particular name exists - the fact that you can have >> >>multiple >> >> objects with the same name in a folder is actually a representation >>of >> >>the >> >> underlying data model, which supports this capability.
>> >> If you just want to construct a path for a particular file, you can >> >> probably start by walking upwards to the file's parent, grandparent, >> >>etc., >> >> until you get to the sync folder it's ultimately contained within. >>You >> >> can also find out which computers it's synced to in this fashion, >>though >> >> it may be associated with more than one.
>> >> Let us know if you have any further questions.
>> >> On 1/31/12 9:57 AM, "Scotty" <craig.mcfarlane.sc...@gmail.com> wrote:
>> >> >So I've been plodding on with the API and now discovered that it >>will >> >> >happily create multiple copies of exactly the same filename. This is >> >> >mad. So now I have to enumerate an entire folder in order to >>determine >> >> >if a file exists already before attempting to upload an update to >>the >> >> >file - so I don't accidentally create a 'new' file. Does anyone know >> >> >of another way to check for the existence of a file without >> >> >enumerating the parent folder?
>> >> >> Just trying to get my head around all the SugarSync concepts of >> >> >> workspaces, shared folders, magic briefcases etc. (do users >>actually >> >> >> understand this stuff?) Anyway, I'm trying to use SugarSync in the >> >> >> same way that I might use a WebDAV (or Dropbox :-) interface - by >> >> >> referring to files and folders by their 'human readable' path. For >> >> >> example, I want to check the modified date on a file which the >>user >> >> >> might consider as being in /My Desktop/My Project/plan.pdf - is >>this >> >> >> possible without having to enumerate all the workspaces, >>collections >> >> >> etc. I know that the URL to that file is persistent and if I know >>it >> >> >> then I can use it - but at this point I haven't enumerated it?
