Goal: reorganize the Horde website to combine wiki.horde.org, dev.horde.org, bugs.horde.org, the documentation parts of pear.horde.org, and www.horde.org. The cvs browser will stay at cvs.horde.org (or possibly in the future svn.horde.org or source.horde.org), and the PEAR package interface will remain as pear.horde.org (or possibly packages.horde.org). Everything else will be combined into one website.
This project will initially imply dropping web mirrors of www.horde.org. FTP mirrors will be unaffected, and it's possible that we will get back to a mirror-able architecture at some point in the future.
ChuckHagenbuch is leading this project and really wants help, especially from anyone who can offer design work.
We want to collect all parts of the Horde site, instead of the current status of things being fractured between the website, dev.horde.org, and the wiki, and people not having a great way of finding useful information in the wiki.
We will create three main logical areas of the site:
We don't have a lot of end user content right now; it's possible that area could be dropped?
Questions raised by this include: where do we store the master docs, CVS or the website? We can automate the process either way - either have make-release.php pull down files from the website, or have a cronjob to update the website from CVS. We could write a renderer for rST docs for the website, and store them there.
We should provide a much more visible sense of ongoing Horde development. Ideas for doing this, possibly requiring work on some infrastructure such as Whups:
post somewhere that once horde 3.2 is out, it will be the only supported stable version. horde 4 work will commence. there will be a migration path to horde 4 from 3.2 once it is stable, but not necessarily at every point in between
horde demo videos
details from http://bugs.horde.org/ticket/6559
Link to todo lists from phpdoc
Link to Todo lists (like http://dev.horde.org/api/framework/todolist.html) from application pages, perhaps from roadmaps? Consolidate so we have docs for an app (api and otherwise), todo list, open bugs, etc. all in one place.
Probably http://dev.horde.org/ is a good place to do this - move current stuff into a sidebar, with default links to online apidoc for all the apps; ideally a custom phpdoc theme with our frame, the generated hordedoc documentation, links to wiki pages, etc.
http://www.ii.com/internet/messaging/imap/isps/ - lots of horde mentions. need to blog!
"while looking for mature code to combat XSS, Bob had
pointed out the CodeIgnitor which EE is built on top of. The CodeIgnitor people listed
where they got their inspiration from and basically if you follow the chain, it ends up
back at Horde"
I just want to let everyone know that ossec
(an open source project for log analysis) now
supports Horde IMP logs. More information:
The Borderware MXtreme Firewall is a Mail proxy against SPAM.
Every user has a SPAM-Folder on the Proxy and is able to log in.
The mailbox-GUI seems to be IMP (the URLs are like
use of Zend_Feed (== Horde_Feed) http://www.dotvoid.com/view.php?id=71
>Sesha may not be cool, but it works well.
We use it at the University to track hardware, software, office
equipment and furniture ... plus I recently repurposed it as
'Keybox' to track all of my accounts and passwords.
Maybe the reason it has so little activity is because no one knows it
exists (isn't listed on the Horde web site unless you go to CVS/Modules).
http://spriggs.no-ip.info/cgi-bin/trac.cgi/wiki/Programming/HordeWTG"Looking at the horde website for the first (serious) time, I'd say that Jan's paper (http://www.horde.org/papers/fosdem2005/) is an excellent
Point being, an "overview" link might be useful."
Taking the Symfony homepage by example, their first topic on the sidebar is "Discover": 1. Read the about page, 2. build your first project or 3. start browsing the book. That's the intro ZF still doesn't have. A "what is this and how this can help me?" page is missing.From Duck:
Then I mission 3 basic Wiki pages. Maybe just a little Wiki reorganization will help a lot.
Imagine that you persuade an administrator that decides to use Horde. The first problem is the complexity of Horde. The first things that comes into my mind is ?Where is the 'my Horde first installation link'??. A link that explains the first step to do after successful horde install. Like adding users, set permissions. Maybe this Wiki exist but are not directly accessible.
Then image a fist time user. The help is outdated. Some informations is available in Wiki but not linked from help. Even if the user finds the Wiki, the first page don't consist of a list of all available topics. Use must directly see what they need, not search it, or get confused on what they must read FAQ or Howtos, that are in fact administration tips not user manual etc. You can get KDE documentation as example. Is a pure end user explanation with screen shots.
And last but not least, the first time developer. There is no general explanations of the concepts of programing in horde or application interaction. Some info are available in Library but again not linked in Wiki. Then api documentations is not enough. The programmer must always find out what methods does, which methods uses what they do and so on. The job is made harder by not having a class index end explanation. You must actually open every class and read what it does or look out the sources. I purpose a general framework Wiki page with all explained classes with piratical examples.
The conclusion is that all that we must give more attention of first time users and Horde, and much more on end user documentation.
Subject: [nyphp-talk] CAKE Ain't Soup!
In defense of Brian Daley's rant about CAKE and contrary to Nate Abele's illness,
I believe Brian's point are well founded and justified completely.
As a complete CAKE novice, I knew/know nothing about Cake except the misinformation that is contained on their home page, i.e *"No Configuration* - Set-up the database and watch the magic begin". So I decided to check it out to see for myself what all the hype was about so after wading through a miriad of "give us money" I finally was able to download the package and attempted to install it on my local Apache Webserver. Give that the installation instruction are clear as mud, I attempted to install it like any other PHP Application but when I attempted to run it, I get a "Your database configuration file is not present." and a screenful of junk that tells me nothing about how to install the product, except an instruction that says, "run the install" but never says what that is. Installation instructions, never mind documentation, are suppose to be specific, precise and correct. Cake is none of the above.
Cake may be cake but it is certainly not soup!
Cake may be indeed a great leap forward but if you can not install it "out of the box" no one will ever know. I, personally, don't "shop around" for information that isn't where it is "suppose" to be. That means that Cake only had one shot to impress me, they did, negatively! All the whining on the planet won't fix an installation process that is fatally flawed.
We're using Symfony for a major project. Yahoo Bookmarks is built on
Symfony. Its pretty good (totally OOP and lots of Railsisms in it).
The Yahoo! team had to re-architect several parts of the framework to get it to do what they wanted. Regardless of that, I hear they were having some significant scaling issues. The Firefox Add-ons portal (https://addons.mozilla.org/) was built on CakePHP, and you can check out the source code here: http://svn.mozilla.org/addons/trunk/site/app/. To date, the site has handled the arguably higher load without a hitch.
Back to the Project List