[Kamailio-Devel] [SR-Dev] [Serdev] AVPs

[Jan Janak]

On 16-12 15:59, Andrei Pelinescu-Onciul wrote:
> On Dec 16, 2008 at 15:58, Jan Janak <jan at ryngle.com> wrote:
> > 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 at 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.
> 
> No. it's not about the framework, is about the "functions that didn't fit
> anywhere else" being moved to some select module in the future (from my
> point of view this has very very low priority).

  Ah, I understand now, thanks. Yes, moving those functions away from the core
  makes sense to me.

    Jan.