Dropbox library in LC 9 - centralise the access token?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Dropbox library in LC 9 - centralise the access token?

Bob Sneidar via use-livecode
The new Dropbox library is (going to be) great. But while it's still only in
DP, can I suggest a modest improvement?

Every single command in the library takes an access token as the first
parameter. Given that most uses of the library will involve multiple calls;
and the cases where an app is juggling two different dropbox accounts will
surely be vanishingly small; wouldn't it be much more elegant if there was a
single command "dropboxSetAccessToken" or similar, to normally be used just
once in a session - then every other command would drop that parameter?

Ben

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Dropbox library in LC 9 - centralise the access token?

Bob Sneidar via use-livecode
so file a qr.  since it's written in LC it should be doable by either of
us...or anyone

On Wed, Oct 11, 2017 at 12:12 PM, Ben Rubinstein via use-livecode <
[hidden email]> wrote:

> The new Dropbox library is (going to be) great. But while it's still only
> in DP, can I suggest a modest improvement?
>
> Every single command in the library takes an access token as the first
> parameter. Given that most uses of the library will involve multiple calls;
> and the cases where an app is juggling two different dropbox accounts will
> surely be vanishingly small; wouldn't it be much more elegant if there was
> a single command "dropboxSetAccessToken" or similar, to normally be used
> just once in a session - then every other command would drop that parameter?
>
> Ben
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Dropbox library in LC 9 - centralise the access token?

Bob Sneidar via use-livecode
And I don't know how modest it will be - the syntax of every command in the
library would have to be updated, which means everyone's code (who is using
the library) would have to update it.
We could also have a new dropbox library that implements this, but then it
would be up to the team to deprecate this one, or we would have competing
libraries.

On Wed, Oct 11, 2017 at 1:02 PM, Mike Kerner <[hidden email]>
wrote:

> so file a qr.  since it's written in LC it should be doable by either of
> us...or anyone
>
> On Wed, Oct 11, 2017 at 12:12 PM, Ben Rubinstein via use-livecode <
> [hidden email]> wrote:
>
>> The new Dropbox library is (going to be) great. But while it's still only
>> in DP, can I suggest a modest improvement?
>>
>> Every single command in the library takes an access token as the first
>> parameter. Given that most uses of the library will involve multiple calls;
>> and the cases where an app is juggling two different dropbox accounts will
>> surely be vanishingly small; wouldn't it be much more elegant if there was
>> a single command "dropboxSetAccessToken" or similar, to normally be used
>> just once in a session - then every other command would drop that parameter?
>>
>> Ben
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Dropbox library in LC 9 - centralise the access token?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
Ben Rubinstein wrote:
> The new Dropbox library is (going to be) great. But while it's still only in
> DP, can I suggest a modest improvement?
>
> Every single command in the library takes an access token as the first
> parameter. Given that most uses of the library will involve multiple calls;
> and the cases where an app is juggling two different dropbox accounts will
> surely be vanishingly small; wouldn't it be much more elegant if there was a
> single command "dropboxSetAccessToken" or similar, to normally be used just
> once in a session - then every other command would drop that parameter?

Does Dropbox limit syncing to a single account?

Will Dropbox always have that limitation?

FWIW Nextcloud allows any number of folders synced with any number of
servers.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Dropbox library in LC 9 - centralise the access token?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
That's why I raise it for discussion here first.

My guess is that if this is only in LC 9, and only since DP-7, then the number
of people already using it will be small - certainly in proportion to the
number who will go on to use it in years ahead!

And for those small number of people (possibly single digits??) the effort to
switch existing code will be pretty low...

Ben

On 11/10/2017 18:05, Mike Kerner via use-livecode wrote:

> And I don't know how modest it will be - the syntax of every command in the
> library would have to be updated, which means everyone's code (who is using
> the library) would have to update it.
> We could also have a new dropbox library that implements this, but then it
> would be up to the team to deprecate this one, or we would have competing
> libraries.
>
> On Wed, Oct 11, 2017 at 1:02 PM, Mike Kerner <[hidden email]>
> wrote:
>
>> so file a qr.  since it's written in LC it should be doable by either of
>> us...or anyone
>>
>> On Wed, Oct 11, 2017 at 12:12 PM, Ben Rubinstein via use-livecode <
>> [hidden email]> wrote:
>>
>>> The new Dropbox library is (going to be) great. But while it's still only
>>> in DP, can I suggest a modest improvement?
>>>
>>> Every single command in the library takes an access token as the first
>>> parameter. Given that most uses of the library will involve multiple calls;
>>> and the cases where an app is juggling two different dropbox accounts will
>>> surely be vanishingly small; wouldn't it be much more elegant if there was
>>> a single command "dropboxSetAccessToken" or similar, to normally be used
>>> just once in a session - then every other command would drop that parameter?
>>>
>>> Ben
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>>
>>
>> --
>> On the first day, God created the heavens and the Earth
>> On the second day, God created the oceans.
>> On the third day, God put the animals on hold for a few hours,
>>     and did a little diving.
>> And God said, "This is good."
>>
>
>
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Dropbox library in LC 9 - centralise the access token?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
 > Does Dropbox limit syncing to a single account?

As far as I know, yes.

That doesn't mean the API enforces this - only that every app and interface
I've come across for it does - you log in as a given account, and you're
operating on that account. There is a folder "~/Dropbox" (or Windows
equivalent), and that's the synced folder. I don't actually know what happens
if, for example on a desktop, you log out of one account and into another -
what it does to the contents of the "Dropbox" folder.

I assume this is by design - the chief virtue of Dropbox is its simplicity.

In principle I think that a new app, e.g. built in LiveCode, could perfectly
happy operate on a number of accounts simultaneously. But my proposal in no
way prevents that - the code that makes a series of calls to the Dropbox API
would precede them with a single call to set the relevant token, rather than
passing that token in every call.  This is how Monte's mergDropbox library
worked, for example.

This is also how the AWS library in LC9 works - you call AWSSetCredentials
first, then all subsequent commands/functions operate on that account, until
you call AWSSetCredentials again to switch to another one. There might be some
virtue in consistency!

In the same way, you make one call to cameracontrol to select which camera
subsequent calls refer, rather than passing "front" or "back" in every call.
The same way in the printing library you set the printer you're addressing. Etc..




On 11/10/2017 18:12, Richard Gaskin via use-livecode wrote:

> Ben Rubinstein wrote:
>> The new Dropbox library is (going to be) great. But while it's still only in
>> DP, can I suggest a modest improvement?
>>
>> Every single command in the library takes an access token as the first
>> parameter. Given that most uses of the library will involve multiple calls;
>> and the cases where an app is juggling two different dropbox accounts will
>> surely be vanishingly small; wouldn't it be much more elegant if there was a
>> single command "dropboxSetAccessToken" or similar, to normally be used just
>> once in a session - then every other command would drop that parameter?
>
> Does Dropbox limit syncing to a single account?
>
> Will Dropbox always have that limitation?
>
> FWIW Nextcloud allows any number of folders synced with any number of servers.
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Dropbox library in LC 9 - centralise the access token?

Bob Sneidar via use-livecode
Most of the filestore apps, be they box, dropbox, google drive,
oneDrive, etc. only operate on one account at a time.  That's one of the
nice things about the API's - you can operate on an unlimited number from
your app.

On Wed, Oct 11, 2017 at 2:00 PM, Ben Rubinstein via use-livecode <
[hidden email]> wrote:

> > Does Dropbox limit syncing to a single account?
>
> As far as I know, yes.
>
> That doesn't mean the API enforces this - only that every app and
> interface I've come across for it does - you log in as a given account, and
> you're operating on that account. There is a folder "~/Dropbox" (or Windows
> equivalent), and that's the synced folder. I don't actually know what
> happens if, for example on a desktop, you log out of one account and into
> another - what it does to the contents of the "Dropbox" folder.
>
> I assume this is by design - the chief virtue of Dropbox is its simplicity.
>
> In principle I think that a new app, e.g. built in LiveCode, could
> perfectly happy operate on a number of accounts simultaneously. But my
> proposal in no way prevents that - the code that makes a series of calls to
> the Dropbox API would precede them with a single call to set the relevant
> token, rather than passing that token in every call.  This is how Monte's
> mergDropbox library worked, for example.
>
> This is also how the AWS library in LC9 works - you call AWSSetCredentials
> first, then all subsequent commands/functions operate on that account,
> until you call AWSSetCredentials again to switch to another one. There
> might be some virtue in consistency!
>
> In the same way, you make one call to cameracontrol to select which camera
> subsequent calls refer, rather than passing "front" or "back" in every
> call. The same way in the printing library you set the printer you're
> addressing. Etc..
>
>
>
>
> On 11/10/2017 18:12, Richard Gaskin via use-livecode wrote:
>
>> Ben Rubinstein wrote:
>>
>>> The new Dropbox library is (going to be) great. But while it's still
>>> only in DP, can I suggest a modest improvement?
>>>
>>> Every single command in the library takes an access token as the first
>>> parameter. Given that most uses of the library will involve multiple calls;
>>> and the cases where an app is juggling two different dropbox accounts will
>>> surely be vanishingly small; wouldn't it be much more elegant if there was
>>> a single command "dropboxSetAccessToken" or similar, to normally be used
>>> just once in a session - then every other command would drop that parameter?
>>>
>>
>> Does Dropbox limit syncing to a single account?
>>
>> Will Dropbox always have that limitation?
>>
>> FWIW Nextcloud allows any number of folders synced with any number of
>> servers.
>>
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Dropbox library in LC 9 - centralise the access token?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
On Wed, Oct 11, 2017 at 1:02 PM Ben Rubinstein via use-livecode <
[hidden email]> wrote:

>
> In principle I think that a new app, e.g. built in LiveCode, could
> perfectly
> happy operate on a number of accounts simultaneously. But my proposal in no
> way prevents that - the code that makes a series of calls to the Dropbox
> API
> would precede them with a single call to set the relevant token, rather
> than
> passing that token in every call.


Personally I don’t care for lower level functional APIs that have you set
something like an auth  token once and then all calls use the token. To
write safe code built on top of the Dropbox library you would have to set
the API token at the beginning of any handler you write that includes a
call to the Dropbox library. Otherwise if you use some other library in
your app built on top of the Dropbox library it could set the token to the
wrong one behind your back. That seems brittle to me.

My 2 cents.

Trevor DeVore
ScreenSteps

>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode