On 16-12 16:44, Daniel-Constantin Mierla wrote:
On 12/16/08 16:33, Jan Janak wrote:
On 16-12 14:49, Andrei Pelinescu-Onciul wrote:
On Dec 16, 2008 at 14:39, Jan Janak
<jan(a)ryngle.com> wrote:
[...]
>>
> Perhaps select implementations can be moved in modules, as well.
> Integration has to be done at some point anyhow.
>
It already is, the core contains the core selects and shared parts.
I think Daniel meant moving also the core selects into a select module
and leave only the shared part in core (like he did for pvars in k).
Would this be a smart thing to do? Lots of modules use or depend on
selects. Maybe we could turn it into a library if there is a need to move it
away from the core, but I personally would leave it where it is now.
same was in K with PVs, most of modules depend on them. But the core
gets pretty fat over the time will all there. While couple of them are
pretty used, some are not at all. Because there will be pseudo-variables
and selects, with lot of overlapping, keeping in core just the shared
part is an optimal solution.
This step can be done along with integration with PVs (removal of
duplicates), perhaps second release of sip-router.
I don't understand. Are you suggesting to move selects somewhere else or do
you want to keep it the way it is now? Note that by "selects" I was refering
to the select framework, i.e. the code that is used to parse select
identifiers, lookup functions to be called and calling those functions.
That code is in ser core now, along with a set of select implementation
functions that didn't fit anywhere else.
Jan.