[dev] Agora Code and Idea Donation

[Chuck Hagenbuch]

Quoting Stephan Hohmann <webmaster at dasourcerer.net>:

> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>
>>> Well, some people consider refbacks to be too noisy to be of any use.
>>> A thought of the following procedure to minimize noise (e.g.  
>>> incoming referrers
>>> from webmail installations):
>>> - See if the referrer is reachable via HTTP(S) (e.g. no 4xx or 5xx response
>>>  code is sent)
>>> - Check if the referrer is pointing to a (X)HTML document (I  
>>> really don't know
>>>  if it's useful to catch incoming links from - let' say - PDF documents)
>>> - Check if there is actually a link to the current page
>>>
>>> If any of th above steps fails, the referrer won't be logged. An  
>>> additional step
>>> might involve extracting the page title of the referrer. I thought  
>>> of a similar
>>> approach for ping- and trackbacks. Possibly it were a good idea to  
>>> let the site
>>> administrator decide if they want "checked" or unchecked linkbacks for each
>>> method individually? From what I hear, some people like to accept pingbacks
>>> openly to allow better linking between content...
>>
>>
>> This sounds like an awful amount of overhead. I'll have to look  
>> into the differences between the different types of referrer  
>> tracking. Interested in what the other devs think as well.
>
> Well, yes. It started off with my desire to display the content of  
> the <title>
> tags of incoming referrers and involved into that. It might be worth  
> it, though.
> A similar approach might be necessary to cut down incoming ping- and/or
> trackback spam anyway. (btw: It seems to be a quite popular method  
> to eliminate
> pingback spam by checking if the source ip address of the XML-RPC call is
> matching the DNS entry of the incoming link. Looks like the number of false
> positives is close to zero)
>
> Also, I think implementation would be pretty easier. After all, it's just one
> HTTP request to pull the page plus some analysis on the response code and the
> page content. Refbacks would only require the additional step of  
> extracting the
> page title.

This sounds like a perfect thing for a queue to handle. I've started a  
Horde_Queue package and keep wanting to return to it.

>>> In addition: If we've got Ansel and its services available, it  
>>> might be an idea
>>> to select any given image in Ansel and offer a "scale to fit requirements"
>>> option. I see some problems regarding the file size limit, though. Maybe it
>>> could be neglected?
>>
>> Not sure what you mean here by neglecting size limits.  What size  
>> limits, in particular are you referring to?
>
> Currently, Agora seems to allow site admins to set a limit to  
> avatars regarding
> file size. I wouldn't really know how to respect that in an automated process
> (set compression levels until it fits? What if it simply doesn't?).

Most services set a max # of pixels rather than max filesize, which is  
easier to enforce. I wouldn't consider this a dealbreaker in v1 of a  
service, though.

>> OTOH it should't be too difficult to build a plugin structure  
>> around our hook calls. You could write a hook to check a directory  
>> for plugin classes then run each one or something similar...
>
> Well, I've got some quite popular functions that would require their own menu
> items as well as new actions for posts. I recently tampered a bit with Habari
> (www.habariproject.org) and found its plugin infrastructure quite enticing.

Can you say more? What would you like to see in a plugin system if we  
went down that road?

-chuck