[SR-Dev] moving modules

[Juha Heinanen]

Andrei Pelinescu-Onciul writes:

 > Before moving more modules consider the following problem cases:
 > 
 > - same module in k uses mi and in ser rpc => for the near future we
 >   cannot choose one over the other, because some functionality will be
 >   lost (e.g. choosing the k module will leave someone wanting a ser like
 >   config having to use mi for one module).

i case of presence, for example, mi cannot be replaced by anything
else, because it depends on other software that is using mi to talk with
presence.

 > - a module includes stuff from other modules (e.g. auth_* & auth) =>
 >   it's probably not safe to replace it with only one version, until the
 >   modules they depend on are merged.

what i did in some cases was that i changed some includes to point to k
includes.  sl module is one example that should be merged soon, because
many modules depend on it.

 > - even if the module exists only in ser or in k, it might be
 >   unmaintained or obsolete (in which case we better make another dir,
 >   something like modules_obsolete or unmaintained and move them there
 >   until somebody volunteers to take over).

i have (and will) only work on modules that i use myself.

 > Part of the problem is if we merge everything now or latter. I think
 > latter is better, unless you want a larger delay (there are just too
 > many modules/interfaces to merge and too few people knowing enough about
 > both projects to do it). There are other points we haven't even
 > discussed yet (like rpc & mi, it doesn't make sense to have 2 management
 > interfaces in the long run).

as i said, it is impossible to get rid of mi.

-- juha