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

[Chris A. Icide]

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.
>
>Well, anyway, that's after 1.2 and Astricon. Busy now.
>
>/O
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20051006/5a534cda/attachment.htm