20 Apr
2009
20 Apr
'09
12:04 p.m.
On Apr 20, 2009 at 11:51, Juha Heinanen <jh(a)tutpro.com> wrote:
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
Andrei Pelinescu-Onciul writes:
If you mean xmlrpc, then it's supported by ser rpc too.
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.