[SR-Dev] moving modules

[Andrei Pelinescu-Onciul]

On Apr 20, 2009 at 11:51, Juha Heinanen <jh at tutpro.com> wrote:
> 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.

If you mean xmlrpc, then it's supported by ser rpc too.

> 
>  > - 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.

I doubt that (I think you mean xmlrpc), but even if that would be the case,
we could leave only the strictly required mi functionality.

Andrei