[
https://issues.apache.org/jira/browse/CONNECTORS-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638889#comment-13638889
]
Andrew Janowczyk commented on CONNECTORS-676:
---------------------------------------------
from their documentation:
---
cursor A string that is used to keep track of your current state. On the next
call pass in this value to return delta entries that have been recorded since
the cursor was returned.
cursor A string that encodes the latest information that has been returned. On
the next call to /delta, pass in this value.
---
it seems that cursor is used both as a page and time marker. this probably
works because the files are given back in chronological order, so the cursor
can operate both as a page and time by saying everything on the next page is
newer. as you iterate through, the altered documents will re-appear on the end
with a later delta. pretty nicely done now that i think about it.
regarding the seeds: i see your point, it could be quite large. i don't see how
to fit a paging paradigm into the connector though. it seems that
processDocuments expects to have a list of the identifiers to begin with.
two questions:
1. is there really an issue of too large a memory footprint if each of the
seeds added is just a string of the filename? even with 100 filenames of 255
characters, the memory consumption is only 204k. i didn't know if manifold
keeps all of it in memory anyway or writes it to the db for usage later.
2. we could mirror the style used in the cmis connector and add only
directories as seeds, though for this to be safe (since the documents are
returned in chronological order) we'd have to iterate through the entire
filelist and add only the directories. this is tricky because later on, there
is no way to request JUST the files which are in a sub-directory, again we'd
have to go through the entire list and do a strcmp to see which files belong in
the directory. the overhead to do that fully for each directory is going to be
a real killer though.
> 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
