Well, if people can get memcached installed on the aur box, and it can be made a requirement for running the aur, then I would have no problem coding up a new rss class that returned rss2.0 _or_ json, based on a passed in parameter. This could wholly replace the existing rss2.php/rss.php mechanism.
I think adding alternate export types (json) to the rss mechanism makes more sense than adding rss logic to the rpc interface. Thoughts? (ooh. I am top-posting now.) On Thu, Oct 8, 2009 at 4:03 PM, Aaron Griffin <aaronmgrif...@gmail.com> wrote: > On Thu, Oct 8, 2009 at 6:02 PM, elij <elij...@gmail.com> wrote: >> On Thu, Oct 8, 2009 at 3:36 PM, Aaron Griffin <aaronmgrif...@gmail.com> >> wrote: >>> Flickr actually has two APIs - a feed based one and a REST based >>> "ajax" API. Both accept a format=foo parameter and json is allowed for >>> both sets. >>> >>> * Is the AUR's rss feed generated per request? Or is it a static output >>> file? >>> * If it's generated, why not simply use the same "format=" thing here. >>> >>> Note that Flickr finds it totally acceptable and ideal to use feeds in >>> addition to their API >> >> As I recall, the feed is generated, then saved to a static file. This >> static file is then served up php script reads it to stdout if not >> expired, until such time as it expires. Then it is generated again. >> >> It appears to work that way as an artifact of the php class/import >> that is being used. There appears to be no option (without adding it >> yourself) to either use an alternate cache mechanism (memcached) or to >> return the feed in alternate formats (other than rss2.0). >> >> This is _mostly_ painting the shed though (or format war, tabs vs >> spaces, etc). Yet, for some reason this just doesn't 'smell' right to >> me though. I can be a bit conservative at times though. >> >> It just seems to me that, getting a list of the latest updates is .. >> wait for ... what feeds are for. > > Yes, exactly... but a "feed" doesn't always have to be RSS :) >
