[dev] Agora Code and Idea Donation

[Stephan Hohmann]

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.

>> To summarize what we've discussed on IRC:
>> I'd find it more logical to let the user set his avatar via Folks. But
>> architecture wise it makes more sense to implement a Horde-wide service.
>>
>> 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?).

>> I had a different idea in the meantime: It should be possible to scan a
>> submitted post for [img]-tags and offer the user to load the embedded images
>> into Ansel and replace the tag accordingly. This could be allowed  
>> or denied by
>> the site administrator and possibly be automated via a user preference. It
>> would surely be convinient. I don't know how CKEditor is dealing with custom
>> BBCode, though.
>
> There is still the issue of actually uploading the image though,  
> unless I'm missing your point.  CKeditor doesn't deal at all with  
> custom BBCode, it barely deals with traditional BBCode (via a  
> plugin).  Hence the need to write a custom plugin.  The ansel plugin  
> would have some additional benefits as well. For example,  we could  
> provide the option of simply including an Img tag for the image, or  
> outputting the JavaScript for embedding the mini ansel  views we  
> have in the post.

Gnah, my idea was mostly rubbish, sorry. I somehow got it mixed up  
with an idea
one of our users had: It mostly dealt with using Ansel as some kind of image
proxy to ensure the constant availability of embedded images.

Regarding the custom BBCode tag... Perhaps something like [img=cid:{$uuid}]
(similar to how attached images are embedded in HTML e-mails) would be better?
The code managing [img] tags would then only need a hook to retrieve the
corresponding images data (location, width, height and possibly thumbnail
location).

>> One other thing: Is there anything like a plugin infrastructure in H4?
>
> Not currently, just hooks.
>
>
>> I'm
>> thinking of customizations that are beyond the scope of hooks for forms.
>> E.g. I'm planing to eventually migrate one of my forums to Agora that's
>> featuring an integrated register for really bad puns. I cannot  
>> imagine putting
>> this into vanilla Agora...
>
> Not sure exactly what this is, but would having a pre and/or post  
> comment hook do what you need?  For example, in Ansel I have a post  
> upload hook that I currently us to send a post to Twitter and/or  
> Facebook notifying of a new image upload. This will probably be more  
> integrated into Ansel in H4, but you get the idea.
>
> 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.

Greets,
   Stephan