ContactList from multiple accounts about jmap

[neilj]

You need getMessageList so you don't have to download a whole account to get the bit you need to display. If you want to merge the results from multiple accounts you will need to merge the results in the client, but you still only need to fetch the first X results given your sort/filter in each account.

I don't think I have much more to say on this subject, but if you're still unconvinced I suggest you bring it up on the JMAP mailing list with a proposed change and we'll see what the consensus is.

[rsto]

Assuming you already know the account ids you could send one JMAP request with getContactList methods for each account (see API request structure). Since it's just one HTTP request, it's cheap for the client.

Each of these methods would require its own filter object to filter by "isFlagged".

[neilj]

As rsto said, this is achievable in a single HTTP request using a getContactList call for each account.

[dehart]

Ok I understand. So that would mean that the client always has to re-sort the data because the server only delivers this in a stable order for 1 account at the time?

[neilj]

Yes, if you want to merge the data from two different accounts, you will need to do this in the client.

[dehart]

Do you realize that getContactList is completely useless if the user is using multiple accounts? If sorting and filtering must be done on the client it would mean that all data has to be fetched anyway.

[neilj]

Well, firstly it's not completely useless even in this circumstance as if you need to do filtering you can apply the filter to the request to each account. But yes, the client will have to sort these locally to mix results; this is true whether the different accounts are on the same server (and so can be fetched via a single request) or completely different servers (e.g. an iCloud + FastMail account).

[dehart]

Thanks for the response. To clarify;
When the accounts are on a different server you will have no other option then fetching the lists separately.
When applying the JMAP protocol for business usage most likely the accounts are on the same server.

Scenario:
Use getContactList to search contacts from a specific country sorted by lastName limit to show 50 records to fill the screen.

• Account 1 has Contacts A, B and C
• Account 2 has Contacts M, T and R
• Account 3 has Contacts D, W and N
• Account 4 has Contacts X,Y and Z

Passing 4 getContactList methods each with the same filtering and sorting would give between 0 to 200 contactIds with a max of 50 items shown to the user and a risk of 150 contacts being fetched that are not displayed.

Off course when the data in already synchronized to the client the problem isn't that big. When using a webclient that isn't synchronizing and has 100.000 contacts spread across 15 account it's not usable. (useless is exaggerated)

My suggestion would be to pass multiple accountIds to the get***List functions. Which accepts all accounts found on the same server. This would also mean that IDs need to be unique per server not per account. Implementers could build this silently and still be compatible with the JMAP spec. Should there be a reason this could not be part of the specification that I am not seeing?

In the Perl example were each account is a different SQLite database this would mean multiple DB connections and more overkill on the server as currently on the client. but have all items in the same database indexed by accountId this would be much faster.

I Hope I made the issue I was foreseeing a bit clear like this.

[neilj]

I don't understand your scenario. Why are the contacts on different accounts here? An Account in JMAP defines certain constraints (e.g. unique ids, concurrency constraints, state string to represent current state of the server). If you are enforcing these constraints, you can expose your data as a single "Account" in JMAP and therefore do your query directly. If you can't enforce them you need to make separate queries and merge the results, and keep track of separate state strings and update the individual queries separately and remerge the results if the state on the different accounts change. Not to mention you need to return the account id that corresponds to each result id in the query. I don't see any big advantage to doing this on the server; it adds lots of extra complexity to the spec (it would have to be a whole separate set of API calls and defined semantics), for minimal benefit.

[dehart]

Perhaps I should have started the issue with this: I want to control permissions. (Invisible, readOnly or Write). This could be done when the contacts are in different accounts and inherit the account's permission.

ContactGroup is ManyMany so this is not an option.
Implementers could build an AddressBook extension to control permissions, but this would also mean every future JMAP extension would need to start with some kind of container entity to control permissions. while Account seems very suitable for this.

Exposing the contacts as 1 account would mean they all inherit the same permissions.

When calling getContactList with multiple accountIds you would still get multiple contactList responses with different states per account. While the filter, sorting and paging would be applied to all of them.

[neilj]

Right, so trying to change the semantics of what a JMAP "Account" is is not the right solution to this problem. This is about being able to specify more fine-grained permissions for objects. You can look at the permissions model used on the Mailbox object in JMAP Mail and perhaps think if something similar to this might work for what you want. I'm happy to look at proposals (although please note the focus is currently on core+mail as these are the two specs going through the IETF at the moment; contacts/calendars will be finished later).

[dehart]

The permissions are not the problem but the reason I have Contacts in multiple Accounts.
For the Mail part of the spec the same issue applies:

Why do people have the Messages in multiple E-mail Accounts? the [email protected] Account might be shared while the other Inboxes are private.

To display a unified inbox like Apple Mail does when adding multiple IMAP accounts getMessageList could not be used. Offcourse this can done by the client but why would we need getMessageList if we can't search, filter and paginate over multiple inboxes?