[dev] Agora Code and Idea Donation

[Michael Rubinsky]

Quoting Stephan Hohmann <webmaster at dasourcerer.net>:

> Hello there,
>
> first of all: Thanks for your reply.
>
> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>
>>
>> I've responded below where I have knowledge and an opinion:
>>
>> Quoting Stephan Hohmann <webmaster at dasourcerer.net>:
>>
>>> Hello there,
>>>
>>> I'm stuck with a half-finished forum software weighing around  
>>> 13,000 lines of
>>> code. Since the original dev team has split up, I see no point in  
>>> continuing development on my own. However, I believe some of the  
>>> features might be
>>> interesting for Agora or even Horde itself:
>>>
>>> o XSL/T Based Template Engine
>>>  We have started with Smarty as our template engine but soon ran  
>>> into problems
>>>  when we decided we wanted XHTML as output format.  It is quite  
>>> basic at the
>>>  moment and given the decisions regarding XHTML vs. HTML in H4 I  
>>> do not know
>>>  if it'll fit in... However, it's great for generating RSS and Atom.
>>
>> In general, we are moving all rendering/template type code to  
>> Horde_View. I'm not sure what the other devs feel about this, but  
>> I'd be hesitant to add yet another template solution.  If you think  
>> it would be possible to do what you want while integrating it into  
>> Horde_View, then that might be another story.
>
> Actually, that might be a lot of hassle... There are a lot of  
> unsolved problems
> at the moment. E.g. I've spent little thought on internationalization and
> theming. As XSL/T is turing-complete, I am quite certain there are solutions
> for these. However, it might take some time.
>
> But as I said: It's really great to generate different flavours of XML. And I
> found it to be several magnitudes faster than Smarty (our previous  
> choice for a
> template engine).
>
>>> o Linkbacks
>>>  Finding out how a thread is linked is quite interesting but  
>>> usually requires
>>>  logfile analysis. We wanted a more active approach and keep track  
>>> of incoming
>>>  referrers by the forum software itself. In addition to this, we wanted to
>>>  allow linkbacks via the pingback XMLRPC call as well (and  
>>> possibly trackbacks
>>>  as used by Wordpress). This could be interesting for other modules serving
>>>  community content as well (mostly Wicked and Ansel).
>>>  I had some good ideas to eliminate spam and noise. But there's nothing in
>>>  code yet...
>>
>> There is an (old) open ticket http://bugs.horde.org/ticket/6769 for  
>> this in Jonah's queue. In H4 this will probably be implemented as  
>> part of the Horde/Content system, which means that any applications  
>> wanting to take advantage of this will need to make their content  
>> available to Horde/Content. This is one reason I haven't done this  
>> yet. I'm in the process of rewriting Jonah and this is on my list  
>> as well. So, any work towards this goal is welcome.
>
> Ah, okay. Have you considered supporting refbacks as well?

I don't see any reason why we shouldn't.


>>> o Meaningful URLs
>>>  Apart from being pretty, we wanted our URLs to express "is-a," "has-a" or
>>>  subset relations. A nice sideffect: This allows for hackable URLs. I.e.
>>>  you could take away the last segment of a URL (up to the last "/") and
>>>  move up in the logical structure. E.g. /help would point to the  
>>> general help
>>>  while /help/text would be the help page regarding text formatting.
>>>  We used a Chain of Responsibility to achieve this. But I'm certain
>>>  Horde_Routes can do the same.
>>
>> Yes, this is a goal for a number of our applications. Some apps  
>> already has a sort-of solution via rewrite rules. In H4 the goal is  
>> do this where it makes sense via Horde_Routes. There is at least  
>> one open ticket on the bug tracker (I think it's for Jonah) related  
>> to this. If you want to work on this, we should get input from  
>> other core devs before we settle on a specific url scheme.
>
> Well, I would want to stop using the CoR-pattern. Don't know if I'd  
> contribute
> to Horde_Routes, really...

Not really required to contribute to Horde_Routes, per se. You just  
need to define the routes you want, and implement some sort of  
dispatcher to decide what to do with the incoming match.


>>> I also had some ideas on how to link some existing modules into Agora:
>>> o Ansel
>>>  Ansel could be used to manage forum avatars as well as provide a one-click
>>>  hosting solution for images.
>>
>> What would the advantage of using Ansel to manage the Avatars vs a  
>> more general VFS based storage? If it *is* used, it should be done  
>> as an application-specific scope in Ansel so the gallery is not  
>> visible from within Ansel itself. It should also not be the *only*  
>> was of managing this.
>
> Okay, maybe I got a little carried away here... The idea was to let a user
> select his avatar select via one of the following ways:
>  - Specify a remote image (if this is allowed by the site admin)
>  - Use a gravatar
>  - Select an image out of one's own gallery from within Ansel
>
> In that context it didn't really occur to me that Agora could handle  
> this itself
> via a VFS.

Having the user being able to pick their Avatar from an existing  
Ansel-hosted image, along with the other choices you mention is a  
viable option. The image could then be stored separately in Agora, or  
managed in a privately scoped Ansel share.

Something else to consider is to have a Horde Avatar service, which  
could manage the user's avatar and provide it to any Horde application  
(or an external site for that matter) that requests it. The service  
could have the same options for selecting an avatar as you previously  
mentioned.

>> Ansel can already host images for any arbitrary scope using it's  
>> API. Related to this, I'm in the process of writing a  
>> plugin/extension to the rich text editor we use for inserting  
>> images from Ansel into a post.
>
> Sounds great... I thought about a special BBCode tag to insert  
> images right out
> of Ansel.

There was a discussion somewhere (can't find the link at the moment)  
about something similar to this, though I don't remember what the  
outcome was. This might be a viable option, but we would need to  
either customize the (very incomplete)BBCode plugin for CKEditor or  
add an entirely new editor type. IMO, I'm not sure either of these  
options would be worth it.

>>>  threads. It might be better to let Agore handle this. But since Trean is
>>>  already there...
>>
>> The ability to manage favorites via the bookmarks/ api is a good  
>> idea. Keep in mind Trean still needs lots of work, specifically,  
>> it's use of shares is going to be completely rewritten so that  
>> instead of folders, we are going to to move to a tag-based system.
>
> Ah, I wanted to map the structure of the forums in Agora to folders in Trean.
> Tags would make this a bit complicated.

Adding application scopes to Trean, similar to the way Ansel has the  
ability to handle different application scopes might be useful here.

> Also: It might be a good idea to treat bookmarks from within Horde special in
> a way that they will stay valid should the URL of the Horde  
> installation change
> (for whatever reason).

The Horde/Content system would probably be useful here also.

-- 
Mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Reality is merely an illusion, albeit a very persistent one." - A. Einstein