<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Olle E. Johansson wrote:
<blockquote cite="mid434563A6.6090400@edvina.net" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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...
</pre>
</blockquote>
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.<br>
<blockquote cite="mid434563A6.6090400@edvina.net" type="cite">
<pre wrap="">
At some point, we'll say Eureka and solve this. Registration belongs in
the [peer] section.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid434563A6.6090400@edvina.net" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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
<a class="moz-txt-link-abbreviated" href="mailto:Asterisk-Dev@lists.digium.com">Asterisk-Dev@lists.digium.com</a>
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>