Request for a new contrib repository for an extension to synchronizing pages between different XWiki instances

Development
1

Hi xwikiers,

I’m starting working on an extension that will let you selectively synchronize pages between totally different instance of XWiki. I started a design on https://design.xwiki.org/xwiki/bin/view/Proposal/Instancessynchronization if you want to see more details about what’s planned.

However, I have a hard time finding the perfect name for it, so I’m welcoming any enlightened idea.

So far I’m thinking about https://github.com/xwiki-contrib/sync and org.xwiki.contrib.sync for the group id and the java package prefix.

2

Looking at https://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HChoosingthename I’d propose:

  • application-synchronize
  • application-instance-synchronization

Side note: In the past @tmortagne has started the trend of using simple names with prefixes but this wasn’t discussed AFAIK and it’s certainly not on https://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HChoosingthename

So for me any name that doesn’t start with a prefix is not valid ATM.

I’m fine that we discuss using names with prefixes but we need a proposal and an explanation when to use them vs the prefixed names.

3

I much prefer full names instead of abbreviations since it’s our rule in XWiki land in general to not use abbreviations.

4

My worry with sync or even synchronization (or synchronize) is that it’s a bit too generic and there are tons of things that can be synchronized and it doesn’t leave space for another synchronization extension.

The naming guide says:

For the actual project name part ( of the git repository name) it is preferred to use a single word (e.g. application-forum). However, sometimes that is not descriptive enough, so you can either use multiple words next to each other (e.g. application-filemanager) if that makes sense and looks natural enough or, if not, you should separate the words with a dash (e.g. displayer-multiselect-suggest). Whatever you decide, please try to keep it as short and descriptive as possible.

5

+1 for it since it’s very clear what it’s doing. Not sure which package name we would use then org.xwiki.contrib.instancesynchronisation feels a bit long. Maybe org.xwiki.contrib.instancesync would be ok?

6

Another idea would be application-replication (but it’s possibly ambiguous).

7

Yet another idea is to consider this is a global mechanism to define an xwiki federation and then this becomes: application-federation.

8

Seems too large even if appealing :wink:

Syncing is only one way to do a federation. For ex, another way is the Ward Cunningham way where you link the content for the different federation members into the other wikis without syncing (federated wiki).

Yet another way is ActivityPub.

9

Another idea is to give a codename to the feature and use that as a name. Like application-xsync (for XWiki Synchronization) or application-isync (for Instance Synchronization). But I’m not a big fan of non-descriptive names.

10

So far that’s the one I prefer I think. Data replication is what this extension is going to be about, and it’s more precise than “synchronization” which can mean quite a lot of not fully related things.

11

On my side, I’m fine with it.

12

I’m OK with application-replication but maybe we should make it clear that this is only about page replication, unless we think it’s going to be extended later to support replicating other things (like extension index, page likes / ratings or any other data we store outside wiki pages). So I’d be fine with application-page-replication also.

13

Actually this project will contain a generic module and another module will rely on the generic replication API to implement page replication, but other extensions will be able to use the low level API too to copy their own stuff.

14

+1 for application-replication then.