JMAP PushSubscription

[ksmurchison]

Start of JMAP PushSubscription support

[dilyanpalauzov]

Reordaring the elements to

struct pushsub_data_new {
    const char *mailbox;
    const char *id;
    const char *subscription;
    unsigned rowid;
    unsigned isverified;
    time_t expires;
    int alive;
};

will reduce the data needed for the structure. (but it depends how the struct is used)

#include <time.h>
#include <stdio.h>
#include <stdint.h>

struct pushsub_data {
    unsigned rowid;
    const char *mailbox;
    uint32_t imap_uid;
    const char *id;
    const char *subscription;
    time_t expires;
    unsigned isverified;
    int alive;
};

struct pushsub_data_new {
    const char *mailbox;
    const char *id;
    const char *subscription;
    unsigned rowid;
    unsigned isverified;
    time_t expires;
    int alive;
};


int main() {
  printf("%lu\n", sizeof(struct pushsub_data));
  printf("%lu\n", sizeof(struct pushsub_data_new));
  return 0;
}

prints

$ clang -Wpadded pad.c -o pad && ./pad
pad.c:7:17: warning: padding struct 'struct pushsub_data' with 4 bytes to align 'mailbox' [-Wpadded]
    const char *mailbox;
                ^
pad.c:9:17: warning: padding struct 'struct pushsub_data' with 4 bytes to align 'id' [-Wpadded]
    const char *id;
                ^
pad.c:16:8: warning: padding size of 'struct pushsub_data_new' with 4 bytes to alignment boundary [-Wpadded]
struct pushsub_data_new {
       ^
3 warnings generated.
56
48

[ksmurchison]

The existing struct matches those in the other *_db.h files. I'm not sure we are too worried about 8 bytes

[dilyanpalauzov]

#include "config.h"? Thus "" instead of <>.

[ksmurchison]

The existing #include matches the other source files

[elliefm]

Looks okay on a first read, a few nits here and there

[elliefm]

Compiler will whinge about %lu on platforms where size_t is not unsigned long, IIRC maybe the BSDs are like this. We have SIZE_T_FMT to deal with it:

Suggested change

	fprintf(f, "Content-Length: %lu\r\n", datalen);
	fprintf(f, "Content-Length: " SIZE_T_FMT "\r\n", datalen);

[elliefm]

do we need to check if we've successfully written this file, and bail out if it went wrong?

[elliefm]

sieve mailbox?

[elliefm]

Looks like there's 9 of them, not 10?

[elliefm]

IOERRORs should use xsyslog

[elliefm]

Could this be something like res = mboxname_user_mbox(userid, config_getstring(...));? I don't see what the struct buf gets us here. Maybe it's leftover from an earlier implementation?