[Asterisk-Dev] "register" statement: why can't it reference an account?

[Olle E. Johansson]

Chris A. Icide wrote:
> Olle E. Johansson wrote:
> 
>>>Olle,
>>>
>>>While I understand your point, I disagree with your conclusion.  In
>>>*some* cases, yes, registration is a static configuration, however when
>>>using realtime as a way to create a realtime GUI management system where
>>>you don't want to reload the system(s) every time a change is made,
>>>registration begins to look like a dynamic statement.  However, I don't
>>>have a good solution to the issue of how to handle the fact that some
>>>outside system has changed the value of the register field in the peer
>>>database.  Either asterisk would need to frequently poll the db table
>>>(yuck), or asterisk would need a signal from the outside system to let
>>>it know it needs to re-process all it's peers to see if the value of
>>>register has changed.
>>>    
>>>
>>
>>You disagree first, but then you agree that having Asterisk going through
>>all of the peers to check if we have a registration does not work...
>>  
>>
> Yes, I was thinking on the whole process as I posted, so I guess I
> started off disagreeing that register is a 'static' directive, but I
> agree that no solution proposed so far is a clean solution.
> 
>>At some point, we'll say Eureka and solve this. Registration belongs in
>>the [peer] section.
>>  
>>
> Agreed, and I think we could 'physically' store it in the peer database,
> and still implement your 'registration' table you suggest below, not by
> creating a separate table but just by modifiying the SQL quary by adding
> a WHERE register='yes' to the end of the query and removing any
> registrations from existing peers who have it enabled and aren't listed
> in the query and adding registration to any peers identified by the
> query that don't currently have it set.  This would seem cleaner than
> the separate table, IMHO.
> 
>>  
>>
>>>So I guess moving register= into the dynamic part of realtime isn't
>>>nearly as simple as it sounds.  However for the flat file
>>>implementation, it seems a cleaner solution.
>>>    
>>>
>>A separat table for registrations and a manager command to re-read the
>>database and check for new items would be a cleaner solution. Or maybe a
>>selective query... Hmmm.
>>
EUREKA!

/O