I've previously implemented a Catalyst Model for Dynamic DNS updates using Net::DNS. It worked like a charm. Unfortunately the source code belongs to my employer, and I'm not sure they'll readily agree to release it. However if there's enough interest - I can try.
In any case - its not so hard - a working pilot implementation took less then two days. As for async operation - I'm do not think its worth the trouble if you your apache if forking children, and you are quering local DNS server, for local DNS zones. Regards, Valentin On 6/6/07, Leo Cacciari <[EMAIL PROTECTED]> wrote:
I'm planing to develop a Catalyst::Model::DNS, allowing Catalyst applications to access (and update through dynamic queries) a Domain Name Service. Obviously, the first concern is to not reinvent the wheel. I'm unable to find such a module on CPAN, so it does not seems to exist. However, someone could be working on it out there... If so, please let me know! Now come the questions. First, I'm thinking to use Net::DNS (http://search.cpan.org/~olaf/Net-DNS-0.59/lib/Net/DNS.pm and http://www.net-dns.org/) as an underlying module, wrapping it in a subclass of Catalyst::Module, having the wrapper performing Catalyst-related tasks, e.g. using the Catalyst configuration mechanism instead of the one included in Net::DNS. Is this the right approach? Should I use Net::DNS (which I know for already having used it) or there are other DNS modules better suited for using in a Catalyst model? (see also the second question below). My second question is more generic, but I'll frame it in the context of this mail nevertheless. DNS queries can be time-consuming, thus to avoid blocking the application while waiting for the answer, Net::DNS allows "background queries" (see http://search.cpan.org/~olaf/Net-DNS-0.59/lib/Net/DNS.pm#Perform_a_background_query_and_do_some_other_work_while_waiting_for_the_answer.) How could I make this behaviour accessible to Catalyst controllers/views? What I was thinking was something along the following lines (where generate_unique_identifier does what it says;)): sub submit_request { my $self = shift; my $socket = $self->resolver->bgsend(@_); my $id = generate_unique_identifier(); $self->{pending}->{$id} = $socket; return $id; } sub retrive_answer { my $self = shift; my ($id) = @_; $socket = $self->{pending}->{$id}; return undef unless $self->resolver->bgisready($socket); delete $self->{pending}->{$id}; return $self->resolver->bgread($socket); } I use an indirection, returning an identifier, for two reasons: first, this ensure that the socket reading will be done by the model. Second, this should be easier to integrate in a cache mechanism, which I plan adding to the model. -- Leo Cacciari _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
_______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
