Justin Holmes

In our initial experiments, we imagined a single-module approach to the view logic, with swappable backends. Now that we've switched to a DRF-centric (and DRF-dependent) approach, let's adopt DRF conventions.

This is essentially blocked by this twisted ticket: https://twistedmatrix.com/trac/attachment/ticket/5087/Selection_009.png

Currently, the only way to automatically shut down is via the countdown. However, it will be pretty cool to provide a method, say "self.shutdown_after_current_inquires()" that will shut the reactor down...

Currently, CJDNSInquiry is not smart enough to ask for the "next page" if there is one.

The "Peers" tab is one of the most important pieces of knowledge we can provide to Cirque users. Make it work! Ideally, it needs to be a table of peerdata....

Currently, there's no persistent knowledge in Cirque. A page refresh or a process restart causes complete amnesia. First, let's think about the Django implementation: The dispatch functions (dispatch_result and dispatch_log_event)...

Currently, the following barriers exist to administration of multiple nodes: - CJDNSAdminClient doesn't know or care which node is sending data to it. It has no way of distinguishing one...

We need a form which takes, at a minimum, the following fields: - Node IPv4 Address (Adding IPv6 will be great too, but we can't do that until this Issue...

Doesn't work after kernel upgrade.

1

In syslog, I get: `8814au: version magic '5.8.0-28-generic SMP mod_unload ' should be '5.8.0-31-generic SMP mod_unload` If instead I try to build the deb, I get: ``` (Reading database ......

The method takes only a long URL: https://github.com/bitly/bitly-api-python/blob/master/bitly_api/bitly_api.py#L392 ...but the API documentation says that the endpoint accepts "a long URL or a Bitlink" with commensurate parameters for each. http://dev.bitly.com/links.html#v3_link_lookup