What features may require schema changes?

What features will require additional db fields?

• Storage requirements for SASL authentication for s2s?
• Other JEPs?
• User forwarding address?

Schema feature requests

• Ticket #72 - several suggestions
• JS#2337 - ability to disable an account
• JS#2617 - store non-plaintext passwords
• JS#3357 - logging time of user login
• JS#3384 - message archiving
• JS#3718 - shared roster groups
• JS#4277 - online / offline status in db
• JS#4602 - offline message quota & expiry
• JS#4706 - better vcard support

c2s (authentication)

One table at present - authreg:

CREATE TABLE `authreg` (
   `username` TEXT, KEY `username` (`username`(255)),
   `realm` TINYTEXT, KEY `realm` (`realm`(255)),
   `password` TINYTEXT,
   `token` VARCHAR(10),
   `sequence` INT,
   `hash` VARCHAR(40) );

sm (session manager storage)

normalisation

Currently, sm tables are not normalized, i.e. there are several tables with collection-owner as primary key, e.g. active and logout. Should these be normalized?

vcard

Currently:

CREATE TABLE `vcard` (
   `collection-owner` TEXT NOT NULL, KEY(`collection-owner`(255)),
   `object-sequence` BIGINT NOT NULL AUTO_INCREMENT, PRIMARY KEY(`object-sequence`),
   `fn` TEXT,
   `nickname` TEXT,
   `url` TEXT,
   `tel` TEXT,
   `email` TEXT,
   `title` TEXT,
   `role` TEXT,
   `bday` TEXT,
   `desc` TEXT,
   `n-given` TEXT,
   `n-family` TEXT,
   `adr-street` TEXT,
   `adr-extadd` TEXT,
   `adr-locality` TEXT,
   `adr-region` TEXT,
   `adr-pcode` TEXT,
   `adr-country` TEXT,
   `org-orgname` TEXT,
   `org-orgunit` TEXT );

• vcard fields are defined in JEP-0054.
• However there are also some fields out there that aren't in JEP-0054, e.g. GENDER. Should 2.1 support these?
• A patch for supporting PHOTO is in bugzilla#29
• It's difficult to map vcard elements onto a single table. For example there can be multiple phone numbers with different attributes, e.g. HOME, VOICE, FAX, etc.

queue (offline storage)

CREATE TABLE `queue` (
   `collection-owner` TEXT NOT NULL, KEY(`collection-owner`(255)),
   `object-sequence` BIGINT NOT NULL AUTO_INCREMENT, PRIMARY KEY(`object-sequence`),
   `xml` MEDIUMTEXT );

• Add changes to facilitate message expiry via database queries, e.g. add a message timestamp field, and a type of message field (message, subscription, etc.)
• A hash of the message XML to aid in detecting duplicates - e.g. see Bugzilla#47

other storage requirements

s2s

SASL authentication

ACLs

Should these be retrievable from storage?