shaunduncan / django-monocle Goto Github PK

Pending on #5, the twitter api fixture needs to change from http:// to https://.

https://twittercommunity.com/t/restricting-api-twitter-com-to-ssl-tls-traffic/12331

The README is quite outdated. Plus better documentation of the entire infrastructure, rationale, caveats, etc should be fully documented.

Django is great and all, but this app could be useful for lots of things. Work on moving the django specific stuff to some contrib folder so you can add support for other frameworks later.

As configured, twitter urls for photos (i.e. https://twitter.com/example/1234567890/photo/1) bombs with a 404. The fixture for twitter probably needs to be updated to handle this by explicitly matching [0-9]+ instead of a greedy *

The current admin validation explicitly disallows HTTPS endpoints, since the oEmbed spec says only HTTP should be used. However, Twitter changed their API a while back to HTTPS only, so a lot of things broke. The validation check should be removed.

This is most likely only useful for local development, as asynchronous resource fetching is part of the benefit of this library, but it would be nice to be able to run a django dev server and not have to also worry about running a celery process as well.

From the initial design of monocle, I wanted to avoid large amounts of excessive database calls when trying to match a url to a stored pattern. To do that, when monocle gets imported, a registry object is created in cache containing all the db models and their patterns. This in-memory object is updated with post save/delete hooks so that changes to third party providers will propagate.

This has an unintended side-effect when dealing with multiple running instances. Since the registry is stored in-memory, the post save/delete hooks only affect the object in that running instance. For example: if I change something using an admin interface on server X, another instance on server Y will not see the change.

This needs to be fixed by somehow figuring out a better way to quickly match URLs to DB patterns by one of:

1. Caching this in-memory registry in memcached
2. Accepting the overhead of additional DB calls, but being smart enough to limit where possible

Depending on how a Django model is setup, if someone were to have a generic OEmbedURLFIeld that could contain either a URL for an internal provider or one for an external provider, the prefetch signal will always fire.

Is it worthwhile to try and figure a way to selectively fire signals for external providers only?

There's a lot of noise from the library that is logged at INFO level. This is helpful at times, but it should most likely be DEBUG level.

Local development can be a bit of a pain, because it requires both memcached and celery. Issue #8 should help with the celery part, but there should be a setup to not be so reliant on memcached specifically.