I created documentation for PubSub which now Includes description, updated configuration, adhoc commands usage, REST API calls usage, etc.

While not strictly documentation related - why do you need to configure URI in dataSource() instead of directly within PubSub configuration?

Comments:

• Not exists -> Doesn't exist / N/A to

• With this configuration room data for other domains than pubsub.example.com will be stored in default data source - configuration room? osx autocorrection?

• Occupant Use Case === - problem with formatting?

• 5.3. REST API seems to be included twice, under 5. Features and 6. Limitations

• 6.3. Offline Message Sink is also under 6. Limitations (and probably fits better under 5. Features)

Wojciech Kapcia wrote:

While not strictly documentation related - why do you need to configure URI in dataSource() instead of directly within PubSub configuration?

Because, since version 7.2.0 we use instances of DataSource which may be (database connection, database connections pool, MongoDB client instance, etc.)

I decided to move all database connection related settings to single place, because before it was a little messy. You could configure UserRepository@, custom implementation of @AuthRepository@, instance of MUC @HistoryProvider and PubSubDAO to use same database. Also for UserRepository you configured to use 10 connection and for AuthRepository 20 connections.

What you will get is:

• single connection pool with 10 connections used by UserRepository@, @AuthRepository and MUC HistoryProvider

• separate connection pool for PubSubDAO

Why pool was only 10 for AuthRepository if it was configured to have pool with 20 connections?

Why MUC used same pool as UserRepository and AuthRepository but PubSubDAO used separate pool?

There was no logic in this behavior. Moreover if one of pool would be reconfigured that it was no longer needed it will not be released during rutime - only restart will release this pool!

Because of that I decided to have named data sources (in case of RDBMS - connection pools). This allows us to create and configure pool as we want. Now we can create 2 separate pools for same database URI with different number of connections - not possible before when DataRepository and RepositoryFactory was used! Due to that server database configuration is more flexible.

Moreover I unified database access layer in Tigase XMPP Server which means that from this new version Tigase XMPP Server, PubSub, MUC will be using same implementation of database connection pools. This unified connection pools provide support for having separate databases for different domains.

Comments:

• Not exists -> Doesn't exist / N/A to

Fixed

• With this configuration room data for other domains than pubsub.example.com will be stored in default data source - configuration room? osx autocorrection?

CTRL-C/CTLR-V between documentations as this section was very similar. I missed this one reference to room and not updated this part.

• Occupant Use Case === - problem with formatting?

This section is copied from Tigase XMPP Server Admin Guide as it should be here. Fixed formatting.

• 5.3. REST API seems to be included twice, under 5. Features and 6. Limitations

Linked twice to same subdocuments. Fixed.

• 6.3. Offline Message Sink is also under 6. Limitations (and probably fits better under 5. Features)

Same as above.