[
https://issues.apache.org/jira/browse/CONNECTORS-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638356#comment-13638356
]
Andrew Janowczyk commented on CONNECTORS-676:
---------------------------------------------
to be honest, i wasn't very sure about the threading. i used the CMIS connector
code as a starting point so all the threading should be exactly the same as in
there.
1) the connector right now indexes the WHOLE dropbox, which while useful is not
as customizable as i'd like. my plan is to use the path Parameter as a filter
to say "i only want to index things in this directory of my dropbox" but i'm
not sure if that is better or not. maybe it should be a multi select where its
possible to add multiple directories? i looked at some of the sample code from
the filesystem connector and it was a bit too painful at the time to try and
merge/modify the necessary parts to get the latter functionality.
2) Good question about the cursor. dropbox supports delta operations, i.e. you
give it a cursor and it will tell you what files have
changed(added/deleted/modified) since that point in time. originally i planned
on using that to keep the dropbox connector synchronized since it results in a
lot less traffic overhead, i.e. directly getting a list of changed files as
opposed to manifold having to query each individual file it knows about to see
if it has changed or not. in the end, manifold didn't seem to support that as
well as i was hoping, since getDocumentVersions is always called and retrieves
the revision directly from dropbox. at some point it could be interesting to
use the cursor, and i left it since it was only a string. if you feel like it
should be removed, it can be without harm.
3) i see your point. i'm not sure how to go about generating a list of all the
possible errors the calls can cause though.it seems that all of the exception
would would occur in the DropboxSession class, so at least its localized. they
have a list of standard API errors listed here:
https://www.dropbox.com/developers/core/api which are summed up as:
400 Bad input parameter. Error message should indicate which one and why.
401 Bad or expired token. This can happen if the user or Dropbox revoked or
expired an access token. To fix, you should re-authenticate the user.
403 Bad OAuth request (wrong consumer key, bad nonce, expired
timestamp...). Unfortunately, re-authenticating the user won't help here.
404 File or folder not found at the specified path.
405 Request method not expected (generally should be GET or POST).
503 Your app is making too many requests and is being rate limited. 503s
can trigger on a per-app or per-user basis.
507 User is over Dropbox storage quota.
5xx Server error. Check DropboxOps.
i guess there is a lot that could go wrong for each request. instead of the
individual classes throwing a general dropboxexception, maybe its better to
have a definite set of errors? the problem is that the dropbox sdk methods only
throw a dropboxexception, so to see which exceptions are possible for which
call is a bit challenging.
i'll give you patch a try later in the week and report back.
> Connector for dropbox
> ---------------------
>
> Key: CONNECTORS-676
> URL: https://issues.apache.org/jira/browse/CONNECTORS-676
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Dropbox connector
> Affects Versions: ManifoldCF 1.1.1
> Reporter: Andrew Janowczyk
> Assignee: Karl Wright
> Fix For: ManifoldCF 1.2
>
> Attachments: dropbox-patch.patch
>
>
> Pretty straight forward. It'd be nice to have a connector which can read from
> dropbox.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
