Custom Query (1173 matches)


Show under each result:

Results (106 - 108 of 1173)

Ticket Resolution Summary Owner Reporter
#543 no-action atom feed IDs: reevalaute taguri Elrond

Our atom feeds use taguris (RFC 4151).

First thing to re-evaluate: Do we want to/have to use taguris in this place? There might be good reasons to want this.

taguris have the form {ownerid_namespace}:{localpart}. This is so they are human generatable AND universal unique. the {ownerid_namespace} is formed of {DNSname_or_email},{date}. The date is the time when the domain/email was owned by the author. This is so that a domain can go to a new owner, which in turn has a new namespace.

For feeds owned by a user, we can use the registration date of the user. We currently use the *current* year. Which is plain wrong. Because the id should never change after first being shipped. So this should be fixed soon.

For site feeds we currently use 2011 as the date. We probably should switch this over to something like the "deploy date". The problem is how to find out about it. We could use the date of the oldest entry in the db, but that will change when the oldest image gets deleted by the owner. ("You may not delete the master goblin image.", hoho). No easy solution currently available.

#544 wontfix Provide .url_for_self for the Base model spaetz

# We have to pass in an "urlgen" object to MediaEntry().url_for_self() to actually get the url. Being attached to the request, this means we have to carry around the request object all over the place rather than having that encapsulated nicely. Compare to django's "get_absolute_url()" which does not need such complexities. (I also think we should implement a get_absolute_url template in the Base model class, to enforce uniformity by the way).

# in contrast to werkzeug tools, this always returns relative URLs, so the URL generation in the atom feed that requires absolute urls looks for example:

werkzeug.urls.Href(self.request.host_url (

when what I want is:


(or even better a more consistent media_entry.get_absolute_url()) It should be possible to enforce absolute external urls easily without having to manually parse and fudge the request in every caller.

# Nitpick: MediaEntry.url_for_next and url_for_prev are defined in, while url_for_self is defined in This should be made consistent.

Things would be easier if the url generation did not depend on the request-specific MapAdapter (request.urlgen), which it currently does. Not sure, how this could be improved.

To sum up:

  • At the very least, this bug should be about adding an external=True parameter that will return absolute, external URLs.
  • The url generation should be defined in the same places (mixin or models)
  • Optionally, we would implement a "get_absolute_url" in the Base model that all subclasses can override, so we can use the same consistent interface for all.This could be the same as "url_for_self" here for now.
  • Ideally, we don't have to pass in the request into the url_for_self function so we don't always have to carry that around and to simplify things. However, I don't see an easy way to fix that, so this could be a step 2 of this ticket.
#547 duplicate Need better PuSH mechanism spaetz

When we submit new media we send out the notification to the PubHubSubbub (PuSH) hub as soon as we uploaded it, which will try to fetch and distribute updated atom feeds. The problem is that with asynchronous processing, there might be no processed media yet and the feed will not yet have changed.

We therefore need a) a hook when media processing has finished b) somehow make use of the hook to actually push out notification of updated feeds to the PuSh hub.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.