fastmail / jmap-tester Goto Github PK

Once rurban/Cpanel-JSON-XS#105 is fixed, should we require that as a minimum version? Or recommend it?

That will mean we actually throw exceptions (instead of serialize to undef) if someone accidentally passes an object in, which I think is far better behaviour

Hello there!

While looking at this page I notice that examples provided are made up of anachronic getMailboxes calls. This history of this repository shows no activity for the past few years apparently...

Being a server implementor of the JMAP spec I would be very interested in a tool to check our implementation (and our understanding...) of the spec.

At first glance, the JMAP website is misleading and led me think that such a tool exist already for RFC-8621...

Is there any plan to modernize this JMAP-Tester tool?

Cheers,

Since forever, we have talked about having JMAP::Client as the not-just-for-testing JMAP client. I think this is a good idea. I would like to recommend JMAP::Client over Mail::JMAPTalk.

So, what are the blockers?

1. I think the Futures branch should be completed and merged first, which has a number of downstream implications. (This should likely be its own project.)

2. Decide whether JMAP::Tester::Abort is appropriate outside of abortable subtests

3. Decide whether and how to make JMAP::Typist optional. I believe we should, and the main question is whether it's per-Client or per-request, or both.

4. Brief pow-wow about how Client would play with future planned expansions like: (a) a DataStore-backed cache engine, a la Overture's (b) registered capabilities and automatic accountId selection (c) smarter snap-in method call id generation to allow methods to make backrefs to previous methods without needing to manage their own call ids globally.