Hello from a lurking user and committer!

I'm top-posting because I just want to add our use case to the
discussion which is different from producing a web site and maybe
closer to the original vision of Forrest.

I cannot join in the technical issues regarding cocoon and/or
implementation details.

We (as a company) use Forrest to publish big documents up to 1000 pages
like UI specs. We mainly deliver the static HTML output to developers.

Crucial features for us are
* (s)DocBook as input format, as limited as the sdocbook plugin may be
* Excel as input format, dito for the Excel plugin
* Small and distributed files that we put into svn (working as a team)
* Fast HTML preview, i.e. Forrest in live mode ('forrest run')
* PDF output, as limited as is; we need PDFs for archiving

One direct competitor is Café Solo (http://www.cafesolo.biz, in German).

There's much room for Forrest to improve, we always have some hassles
when a new project starts and a long wish list. We don't have the
resources to add substantially to Forrest beyond our internal hacks :-(

I'd love to contribute more but my (working) focus shifted away from
Forrest and as it is we manage to get along with it. Problems don't hit
the mailing lists since most of them we can resolve internally.

Best regards, cheers and all
Johannes



> -----Original Message-----
> From: ross.gard...@googlemail.com [mailto:ross.gard...@googlemail.com]
> On Behalf Of Ross Gardler
> Sent: Saturday, October 10, 2009 4:51 PM
> To: dev@forrest.apache.org
> Subject: Re: [Important] Status and future direction
>
> 2009/10/9 Thorsten Scherler <thors...@apache.org>:
> >
> > On 08/10/2009, at 21:07, Ross Gardler wrote:
> >
> >> I agree with Tim here, especially the bit where he can't agree with
> me
> >> more ;-)
> >>
> >> I don't know a great deal about Cocoon 3, but I have no personal
> interest
> >> in using it here - sledgehammer to crack a nut. Since I'm not active
> here my
> >> opinion doesn't count for much in that respect though.
> >
> > I am still developing mostly with cocoon in different versions. Just
> a
> > couple of days back I had a chance to use cocoon 3 within droids and
> I have
> > to say it is not sledgehammer anymore. You can use it without any
> sitemap if
> > you want. ...
>
> When the work on Cocoon 3 started I was excited that many of the
> concepts and ideas were what I was calling for in Forrest 2
> (embeddability, simplicty, programmatic control etc.) I've not kept up
> with it, if you have and you say it is not a sledgehammer then I'm
> happy to listen.
>
> >> On 8 Oct 2009, at 13:35, Tim Williams <william...@gmail.com> wrote:
>
> ...
>
> > I have to admit that I am not sure about whole discussion about the
> future
> > of forrest. We have a working product with a small committer
> community
> > behind it. Our user base however is I guess larger then we imagine
> however
> > we do not know them since forrest seems to just work. So no problems
> = no
> > mails = no traffic.
>
> I think this is true. Forrest is great for knocking together web
> sites. If that's all you want then plain vanilla Forrest is great,
> presents no problems and therefore no traffic.
>
> > Regarding the traffic on our commit lists is similar, we do not add
> any new
> > functionality to forrest for a while now and more or less maintain
> the code
> > we have with the feedback from the list and individual test cases.
>
> Here I disagree though.
>
> Forrest was originally created as a way of combining content from
> multiple sources in a single output format. However, the only well
> supported output format is HTML, so if you want to create web pages
> it's great. There are some well supported input formats, but most
> users just use XDoc. Hence Forrest is used to create web pages and
> nothing more.
>
> At its height we had developers who needed the more advanced features
> of merging data formats. However, we live in a different world today,
> most data is available in some kind of syndicated feed that can be
> passed through a simple XSL sheet and we're done. We don't need
> complex pipelining anymore - if we do then there are a number of
> simple GUI tools to provide them in a much simpler way than Forrest
> does.
>
> The world has moved on and the original vision of Forrest, IMHO, is no
> longer relevant. It is for this reason that we are not seeing new
> features - it is not feature complete with respect to the original
> vision (where's version 1?)
>
> > The fear that I have that we will replace one complex beast with
> another.
>
> This is a legitimate fear.
>
> If that's where this discussion took us then you can count me out.
>
> > Does our framework of input, internal and
> > output plugins can be slimed down to a jar that I can add to my
> standard
> > project where I need SOME of the functionality but not all?
>
> IMHO yes - see my weekend hacks on Forrest 2 - that's exactly what
> this is (in proof of concept form). If we remove the complex
> pipelining and focus on embeddable data translation I think there is
> still a space for Forrest. Whilst some people might want the
> pipelining features (to produce websites for example) this should not
> be a part of core Forrest. I'd not object, in fact I proposed, that
> Forrest translations should be embeddable in Cocoon to provide these
> pipelining features. If we did it this way round we would remove the
> dependency on Cocoon, thus allowing us to proceed independently of
> that (or any other project).
>
> > In which
> > programming language do we want to develop to start with? ....
>
> At this stage I don't care. I think that would be a diversion from the
> important topic of whether it should be done at all.
>
> > I do not see forrest in the attic neither. There are still quite a
> bunch of
> > code in our rep that attracts people with certain usecase.
>
> The attic is for code that is not being maintained. It does not mean
> it has no users.  The fact that this conversation is happening shows
> that there is some oversight, but how many of us have done anything
> really useful for Forrest in the last 18 months? (not me)
>
> Can those who have kept the project alive continue to do so? If so why
> hasn't there been a release? I know I have grown tired of answering
> questions for a project I no longer use in new projects and is not
> under active development.
>
> There have been two people in this thread say they think the right
> route is X - so who is going to actually do it? If someone leads,
> others may follow.
>
> Ross
>
>
> --
> Ross Gardler
>
> OSS Watch - supporting open source in education and research
> http://www.oss-watch.ac.uk
>

--
i.A. Johannes Schaefer, Head Usability Ludwigsburg
User Interface Design GmbH, Ludwigsburg (Germany)
phone/fax  +49 7141 37700-46/-99 * mobile +49 170 4914567
e-mail johannes.schae...@uid.com * www.uid.com

Offices:
Martin-Luther-Straße 57-59 * 71636 Ludwigsburg
Hansastraße 7-11 * 44137 Dortmund
Friedrichsring 46 * 68161 Mannheim
Truderinger Strasse 330 * 81825 Muenchen

Legal information according to EHUG:
User Interface Design GmbH; Managing Directors: Dr. Claus Goerner,
Franz Koller; Head office: Ludwigsburg; Commercial register of the
local court of Stuttgart, Germany, HRB 205519