Hi *,
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).
- 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.
- 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).
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).
Andrei
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
On Apr 20, 2009 at 11:51, Juha Heinanen jh@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
Andrei Pelinescu-Onciul writes:
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.
in case of presence, for example, presence modules accepts mi xmlrpc commands from xcap server. the protocol (xmlrpc) and the contents of the messages cannot be changed. also, there is pua_mi module that accepts presence mi requests over xmlrpc.
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.
i don't know what i mean, but the above needs to keep on working.
-- juha
El Lunes, 20 de Abril de 2009, Andrei Pelinescu-Onciul escribió:
Hi *,
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).
Ok, so what is the "standard" to use? rpc? is it decided?
Regards.
-
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
jh＠tutpro.com