You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Mitch Christensen <mi...@informatixinc.com> on 2002/11/12 00:36:44 UTC
FW: Thanks
A lot of people are pulling out a lot of hair over Turbine. Turbine is a
great framework that *needs* to exist (I can find no reasonable
alternative). Unfortunately, it is so poorly documented that many folks
simply walk away after struggling with it.
You can measure this by the number of "Hi, I'm trying to get Turbine working
but I keep getting an XXX error..." postings that come across, and the user
is never to be heard from again.
Isn't there anyone out there that can spend a little time cleaning up the
documentation for Turbine?
Right now, what Turbine needs is documentation, not new features. If anyone
has attempted to extend the turbine schema in any way, or use Intake for
that matter. They quickly realize that it can be an exercise in
frustration, admittedly offset somewhat by the elation you feel when you
finally figure out (after days of searching) what could have been documented
in a couple of hours.
I'm not being critical, it's just that I sympathize with Bill.
The bottom line is that I believe that Turbine should be amassing a larger
user audience than it has (based on posting volumes to this group), and I'm
not sure how much longer Turbine can survive without legitimate
documentation. (And I really think Turbine should survive)
Sorry for the rant.
-Mitch
-----Original Message-----
From: Bill [mailto:bhalpin@collaborativefusion.com]
Sent: Monday, November 11, 2002 9:46 AM
To: mitch.christensen@informatixinc.com
Subject: Thanks
The TRP.action.login option was totally the problem!!!! Thank you so
much, I've been pulling my hair out over this. :)
-b
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FW: Thanks
Posted by Rodney Schneider <ro...@actf.com.au>.
On Tue, 12 Nov 2002 10:36, you wrote:
> Right now, what Turbine needs is documentation, not new features. If
> anyone has attempted to extend the turbine schema in any way, or use Intake
> for that matter. They quickly realize that it can be an exercise in
> frustration, admittedly offset somewhat by the elation you feel when you
> finally figure out (after days of searching) what could have been
> documented in a couple of hours.
Hi Mitch and others,
Many of the Turbine developers are currently busy on other projects at the
moment. So, if anyone out there wants the the Turbine documentation improved
in any way, the best way is to submit changes/additions to the turbine-dev
mailing list. Patches are always welcome :)
Alternatively, you can raise issues with the Turbine documentation in Scarab:
http://nagoya.apache.org/scarab/issues
If anyone out there is a new Turbine user, it would be really helpful for the
Turbine community if you would document Turbine as you learn about it. Any
contributions, no matter how small, are always appreciated.
Thanks,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Documentation (was: Re: Thanks)
Posted by Rodney Schneider <ro...@actf.com.au>.
On Tue, 12 Nov 2002 11:18, you wrote:
> I have thought of three guides to write, but am not sure if they would be
> helpful, or which to do first. Any suggestions?
>
> * Multiple Site Howto -- How to organize classes and actions so that a
> single turbine instance can serve multiple sites that may need to share
> common functionality
The above Howto might be useful to some people, but IMHO there are higher
priorities; see below.
If you look at the Torque documentation, they currently have a Tutorial, a
User Guide and a Developer Guide as well as various Howtos Guides. I think
this would work well for Turbine. I personally think that the current
Turbine 2.x documentation is spread out across too many Howto documents and
that many of these could be compiled into a single comprehensive User Guide
separated into appropriate chapters.
> * Service Howto/Introduction -- What services are, why they are nice, and
> how to write them
I think it would be good if Turbine Services took up a chapter in the Turbine
2 User Guide. See the existing service documentation for a place to start:
http://jakarta.apache.org/turbine/turbine-2/apidocs/org/apache/turbine/services/package-summary.html
http://jakarta.apache.org/turbine/turbine-2/services.html
> * Non TDK Howto -- I found the TDK confusing because it did a bunch of
> stuff that I didn't necessarily want. So I learned about Turbine by
> removing everything, and putting it back in as I needed it. This document
> would be a "tour" in the form of setting up an example app without using
> the TDK.
This would be the Turbine 2 Tutorial and would come with a sample
application, similar in structure to the Torque Tutorial. I think this would
probably be the most important document to write. If we had a Tutorial, we
would no longer need a TDK.
I was in the process of migrating my Turbine 2.1 application over to Turbine
2.2-RC1 a couple of weeks ago, and I began writing a Turbine 2.1 to 2.2
Migration Howto. Unfortunately, work has become very busy so I haven't had a
chance to complete it yet. Paul Smith had also volunteered to rewrite/update
the TDK Howto to reflect the differences between TDK-2.1 and TDK-2.2, but he
is waiting for the final release of TDK-2.2 before he starts.
Regards,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Documentation (was: Re: Thanks)
Posted by pavel kusch <pa...@icecentric.com>.
All of those Howtos would be great and helped lots of people.
pavel
Chris K Chew wrote:
>I have thought of three guides to write, but am not sure if they would be
>helpful, or which to do first. Any suggestions?
>
>* Multiple Site Howto -- How to organize classes and actions so that a
>single turbine instance can serve multiple sites that may need to share
>common functionality
>* Service Howto/Introduction -- What services are, why they are nice, and
>how to write them
>* Non TDK Howto -- I found the TDK confusing because it did a bunch of stuff
>that I didn't necessarily want. So I learned about Turbine by removing
>everything, and putting it back in as I needed it. This document would be a
>"tour" in the form of setting up an example app without using the TDK.
>
>Thanks,
>
>Chris
>
>
>
>>-----Original Message-----
>>From: Scott Eade [mailto:seade@backstagetech.com.au]
>>Sent: Monday, November 11, 2002 5:03 PM
>>To: turbine-user
>>Subject: Documentation (was: Re: Thanks)
>>
>>
>>I had planned to conduct a review of the t2.2 documentation to
>>come up with
>>a list of things that need to be done to bring things up to scratch.
>>Unfortunately I am just too snowed under at the present to get to this.
>>
>>I would be surprised (somewhat pleasantly) if someone steps
>>forward to take
>>up the challenge of bringing the documentation up-to-date. There are also
>>other issues that need to be considered, in particular I don't believe the
>>steps involved in extending the turbine schema have even been fully
>>developed (anecdotal evidence indicates that several users have attempted
>>this to varying degrees of success).
>>
>>I think the best improvement we can hope for in the short term is for
>>specific incremental enhancements to existing documents to correct errors
>>and omissions. These could be posted to the list or better still
>>posted as
>>patches to the existing xdoc files. Updating the xdocs and producing the
>>patches can be a little intimidating at first, but it is pretty simple. I
>>am happy to process documentation suggestions from email through
>>to patches,
>>so if you want you can post a message to the list something like:
>>
>> The ultimate solution to my problem was ... My life would have
>> been much easier if the ... document included the following text
>> just above/just below/replacing ...
>>
>> ... New or replacement text ...
>>
>>I don't think we can expect someone to just step forward and solve this
>>problem. We ALL need to make contributions to achieve the
>>desired outcome.
>>
>>I am not complaining about your rant, but if you could direct a similar
>>amount of energy to providing a small update to the existing documentation
>>that covered the issue at hand then we would be on our way.
>>
>>Documentation patches are welcome. I will also try and assist by
>>processing
>>documentation suggestions contained in email messages through to patches.
>>
>>Cheers,
>>
>>Scott
>>--
>>Scott Eade
>>Backstage Technologies Pty. Ltd.
>>http://www.backstagetech.com.au
>>
>>
>>
>>
>>>From: "Mitch Christensen" <mi...@informatixinc.com>
>>>Reply-To: "Turbine Users List" <tu...@jakarta.apache.org>
>>>Date: Mon, 11 Nov 2002 15:36:44 -0800
>>>To: <tu...@jakarta.apache.org>
>>>Subject: FW: Thanks
>>>
>>>A lot of people are pulling out a lot of hair over Turbine.
>>>
>>>
>>Turbine is a
>>
>>
>>>great framework that *needs* to exist (I can find no reasonable
>>>alternative). Unfortunately, it is so poorly documented that many folks
>>>simply walk away after struggling with it.
>>>
>>>You can measure this by the number of "Hi, I'm trying to get
>>>
>>>
>>Turbine working
>>
>>
>>>but I keep getting an XXX error..." postings that come across,
>>>
>>>
>>and the user
>>
>>
>>>is never to be heard from again.
>>>
>>>Isn't there anyone out there that can spend a little time
>>>
>>>
>>cleaning up the
>>
>>
>>>documentation for Turbine?
>>>
>>>Right now, what Turbine needs is documentation, not new
>>>
>>>
>>features. If anyone
>>
>>
>>>has attempted to extend the turbine schema in any way, or use Intake for
>>>that matter. They quickly realize that it can be an exercise in
>>>frustration, admittedly offset somewhat by the elation you feel when you
>>>finally figure out (after days of searching) what could have
>>>
>>>
>>been documented
>>
>>
>>>in a couple of hours.
>>>
>>>I'm not being critical, it's just that I sympathize with Bill.
>>>
>>>The bottom line is that I believe that Turbine should be
>>>
>>>
>>amassing a larger
>>
>>
>>>user audience than it has (based on posting volumes to this
>>>
>>>
>>group), and I'm
>>
>>
>>>not sure how much longer Turbine can survive without legitimate
>>>documentation. (And I really think Turbine should survive)
>>>
>>>Sorry for the rant.
>>>
>>>-Mitch
>>>
>>>-----Original Message-----
>>>From: Bill [mailto:bhalpin@collaborativefusion.com]
>>>Sent: Monday, November 11, 2002 9:46 AM
>>>To: mitch.christensen@informatixinc.com
>>>Subject: Thanks
>>>
>>>
>>>The TRP.action.login option was totally the problem!!!! Thank you so
>>>much, I've been pulling my hair out over this. :)
>>>
>>>-b
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>
>>>
>><ma...@jakarta.apache.org>
>>
>>
>>>For additional commands, e-mail:
>>>
>>>
>><ma...@jakarta.apache.org>
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
Re: Documentation (was: Re: Thanks)
Posted by Rodney Schneider <ro...@actf.com.au>.
Hi Quinton,
I think a combination of a twiki and a decent set of xdocs would meet your
suggestions outlined below.
Regards,
-- Rodney
On Wed, 13 Nov 2002 03:03, you wrote:
> I would like to suggest that two sections of documentation be created.
>
> One section is driven entirely by user submission. It is not formatted
> in XML. It is very much like a FAQ. The community already has this
> right now in the form of email archives. However, I would like to
> suggest that a web page be dedicated to this somewhere which contains
> only how-to type information. This should make is a little easier for
> people to find the information that they are looking for.
>
> The second section would be the current type of documentation found on
> the jakarta site. This would have to be submitted in whatever form is
> required by Anakia. It would make sense that if it were easier for
> users to submit documentation and see that it is published for everyone
> else to see, they might be more likely to take a few extra minutes to
> document solutions that they had to research.
>
> Also, by looking at the submissions to the user supplied documentation
> site, it would be easier to determine where the "official" turbine
> documentation really need to be improved. We might even see a few
> people in the community who are interested specifically in improving the
> documentation make more progress in this area under this type of scheme.
>
> A perfect example of this is how to use transactions. I am currently
> migrating from 2.1 to 2.2rc1. When I wrote my code in 2.1 for
> transactions, I had to go through the javadocs to figure out how to
> accomplish the task. Not that it was very difficult but it would have
> been nice if a "suggested method" for using transactions was documented
> somewhere. In 2.2, the method for using transactions appears to have
> changed.
>
> I would not mind at all writing a small how-to on this little issue.
> However, if the requirements for me to do this is to figure out some
> specific format, I would be more prone to put it off until I have more
> time to dedicate to it.
>
> On Tue, 2002-11-12 at 09:46, Mitch Christensen wrote:
> > I suspect we are using Anakia for generation of the Turbine site. If
>
> so,
>
> > any documentation must be formatted in XML, per the Anakia
>
> requirements.
>
> > Can someone validate this?
> >
> > What is mechanism for submission? If I write what I believe to be a
> > beneficial howto, who decides that it has applicability, and
>
> incorporates it
>
> > into the Anakia tree and regenerates the site?
> >
> > Could it be that lack of a formal process in the reason there is
> > insufficient/outdated documentation?
> >
> > -Mitch
> >
> > -----Original Message-----
> > From: Quinton McCombs [mailto:qmccombs@nequalsone.com]
> > Sent: Tuesday, November 12, 2002 7:30 AM
> > To: Turbine Users List
> > Subject: Re: Documentation (was: Re: Thanks)
> >
> >
> > Another idea for documentation could be something similar to the Linux
> > Documentation Project. This would allow documents of varying scope.
> > For example a very small how-to could be on transactions.
> >
> > A much larger how-to could be on intake or extending the turbine
>
> schema.
>
> > On Mon, 2002-11-11 at 18:37, Scott Eade wrote:
> > > Great. For new documents we should aim for at least an outline
>
> before
>
> > we
> >
> > > add them as works in progress. If you intend working on these
>
> through
>
> > to a
> >
> > > level of semi-completion then you should look at the existing xdocs
> >
> > and use
> >
> > > that format (it is really very easy).
> > >
> > > I can't recall where the xdoc documentation resides, bit it is
>
> fairly
>
> > easy
> >
> > > to follow an example - e.g.:
>
> http://cvs.apache.org/viewcvs/jakarta-turbine-2/xdocs/howto/extend-user-
>
> > howt
> >
> > > o.xml?rev=1.7&content-type=text/vnd.viewcvs-markup
> > >
> > > Cheers,
> > >
> > > Scott
> > >
> > >Quinton McCombs<
> >
> > Strategic Planner, NEqualsOne
> > 1800 International Park Drive
> > Suite 205
> > Birmingham, AL 35243
> > p: 205.324.8005 x121 800.466.1337
> > f: 205.324.7008
> > e: qmccombs@NEqualsOne.com
> > www.NEqualsOne.com
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
>
> >Quinton McCombs<
>
> Strategic Planner, NEqualsOne
> 1800 International Park Drive
> Suite 205
> Birmingham, AL 35243
> p: 205.324.8005 x121 800.466.1337
> f: 205.324.7008
> e: qmccombs@NEqualsOne.com
> www.NEqualsOne.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Documentation (was: Re: Thanks)
Posted by Quinton McCombs <qm...@nequalsone.com>.
I completely agree!
On Wed, 2002-11-13 at 21:14, Rodney Schneider wrote:
> Hi Quinton,
>
> I think a combination of a twiki and a decent set of xdocs would meet your
> suggestions outlined below.
>
> Regards,
>
> -- Rodney
>
>
> On Wed, 13 Nov 2002 03:03, you wrote:
>
> > I would like to suggest that two sections of documentation be created.
> >
> > One section is driven entirely by user submission. It is not formatted
> > in XML. It is very much like a FAQ. The community already has this
> > right now in the form of email archives. However, I would like to
> > suggest that a web page be dedicated to this somewhere which contains
> > only how-to type information. This should make is a little easier for
> > people to find the information that they are looking for.
> >
> > The second section would be the current type of documentation found on
> > the jakarta site. This would have to be submitted in whatever form is
> > required by Anakia. It would make sense that if it were easier for
> > users to submit documentation and see that it is published for everyone
> > else to see, they might be more likely to take a few extra minutes to
> > document solutions that they had to research.
> >
> > Also, by looking at the submissions to the user supplied documentation
> > site, it would be easier to determine where the "official" turbine
> > documentation really need to be improved. We might even see a few
> > people in the community who are interested specifically in improving the
> > documentation make more progress in this area under this type of scheme.
> >
> > A perfect example of this is how to use transactions. I am currently
> > migrating from 2.1 to 2.2rc1. When I wrote my code in 2.1 for
> > transactions, I had to go through the javadocs to figure out how to
> > accomplish the task. Not that it was very difficult but it would have
> > been nice if a "suggested method" for using transactions was documented
> > somewhere. In 2.2, the method for using transactions appears to have
> > changed.
> >
> > I would not mind at all writing a small how-to on this little issue.
> > However, if the requirements for me to do this is to figure out some
> > specific format, I would be more prone to put it off until I have more
> > time to dedicate to it.
> >
> > On Tue, 2002-11-12 at 09:46, Mitch Christensen wrote:
> > > I suspect we are using Anakia for generation of the Turbine site. If
> >
> > so,
> >
> > > any documentation must be formatted in XML, per the Anakia
> >
> > requirements.
> >
> > > Can someone validate this?
> > >
> > > What is mechanism for submission? If I write what I believe to be a
> > > beneficial howto, who decides that it has applicability, and
> >
> > incorporates it
> >
> > > into the Anakia tree and regenerates the site?
> > >
> > > Could it be that lack of a formal process in the reason there is
> > > insufficient/outdated documentation?
> > >
> > > -Mitch
> > >
> > > -----Original Message-----
> > > From: Quinton McCombs [mailto:qmccombs@nequalsone.com]
> > > Sent: Tuesday, November 12, 2002 7:30 AM
> > > To: Turbine Users List
> > > Subject: Re: Documentation (was: Re: Thanks)
> > >
> > >
> > > Another idea for documentation could be something similar to the Linux
> > > Documentation Project. This would allow documents of varying scope.
> > > For example a very small how-to could be on transactions.
> > >
> > > A much larger how-to could be on intake or extending the turbine
> >
> > schema.
> >
> > > On Mon, 2002-11-11 at 18:37, Scott Eade wrote:
> > > > Great. For new documents we should aim for at least an outline
> >
> > before
> >
> > > we
> > >
> > > > add them as works in progress. If you intend working on these
> >
> > through
> >
> > > to a
> > >
> > > > level of semi-completion then you should look at the existing xdocs
> > >
> > > and use
> > >
> > > > that format (it is really very easy).
> > > >
> > > > I can't recall where the xdoc documentation resides, bit it is
> >
> > fairly
> >
> > > easy
> > >
> > > > to follow an example - e.g.:
> >
> > http://cvs.apache.org/viewcvs/jakarta-turbine-2/xdocs/howto/extend-user-
> >
> > > howt
> > >
> > > > o.xml?rev=1.7&content-type=text/vnd.viewcvs-markup
> > > >
> > > > Cheers,
> > > >
> > > > Scott
> > > >
> > > >Quinton McCombs<
> > >
> > > Strategic Planner, NEqualsOne
> > > 1800 International Park Drive
> > > Suite 205
> > > Birmingham, AL 35243
> > > p: 205.324.8005 x121 800.466.1337
> > > f: 205.324.7008
> > > e: qmccombs@NEqualsOne.com
> > > www.NEqualsOne.com
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> >
> > <ma...@jakarta.apache.org>
> >
> > > For additional commands, e-mail:
> >
> > <ma...@jakarta.apache.org>
> >
> > >Quinton McCombs<
> >
> > Strategic Planner, NEqualsOne
> > 1800 International Park Drive
> > Suite 205
> > Birmingham, AL 35243
> > p: 205.324.8005 x121 800.466.1337
> > f: 205.324.7008
> > e: qmccombs@NEqualsOne.com
> > www.NEqualsOne.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Documentation (was: Re: Thanks)
Posted by Scott Eade <se...@backstagetech.com.au>.
> From: Quinton McCombs <qm...@nequalsone.com>
>
> I would like to suggest that two sections of documentation be created.
>
> One section is driven entirely by user submission.
This is open source - ALL sections are driven by user submission.
> It is not formatted in XML.
The formatting is trivial - if you wont spend 5 minutes figuring out how it
works then just submit to the list and I or someone else will pick it up.
> It is very much like a FAQ. The community already has this
> right now in the form of email archives. However, I would like to
> suggest that a web page be dedicated to this somewhere which contains
> only how-to type information. This should make is a little easier for
> people to find the information that they are looking for.
There are bunches of how-to documents in existence, the trouble is they they
are either out of date, inaccurate, not detailed enough or miss some
important issue.
>
> The second section would be the current type of documentation found on
> the jakarta site. This would have to be submitted in whatever form is
> required by Anakia. It would make sense that if it were easier for
> users to submit documentation and see that it is published for everyone
> else to see, they might be more likely to take a few extra minutes to
> document solutions that they had to research.
It's easy, just do it.
>
> Also, by looking at the submissions to the user supplied documentation
> site, it would be easier to determine where the "official" turbine
> documentation really need to be improved. We might even see a few
> people in the community who are interested specifically in improving the
> documentation make more progress in this area under this type of scheme.
All committed documentation is "Official", be it accurate or not.
>
> A perfect example of this is how to use transactions. I am currently
> migrating from 2.1 to 2.2rc1. When I wrote my code in 2.1 for
> transactions, I had to go through the javadocs to figure out how to
> accomplish the task. Not that it was very difficult but it would have
> been nice if a "suggested method" for using transactions was documented
> somewhere. In 2.2, the method for using transactions appears to have
> changed.
>
> I would not mind at all writing a small how-to on this little issue.
> However, if the requirements for me to do this is to figure out some
> specific format, I would be more prone to put it off until I have more
> time to dedicate to it.
Write it in plain text and submit it to the list for review. Once we are
happy with it I will spend the 5 minutes it takes to apply the xdoc tags.
Once you have actually looked at an xdoc formatted document you will see
that there applying this formatting is a no-brainer. There are no barriers
here - write the document.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Documentation (was: Re: Thanks)
Posted by Quinton McCombs <qm...@nequalsone.com>.
I would like to suggest that two sections of documentation be created.
One section is driven entirely by user submission. It is not formatted
in XML. It is very much like a FAQ. The community already has this
right now in the form of email archives. However, I would like to
suggest that a web page be dedicated to this somewhere which contains
only how-to type information. This should make is a little easier for
people to find the information that they are looking for.
The second section would be the current type of documentation found on
the jakarta site. This would have to be submitted in whatever form is
required by Anakia. It would make sense that if it were easier for
users to submit documentation and see that it is published for everyone
else to see, they might be more likely to take a few extra minutes to
document solutions that they had to research.
Also, by looking at the submissions to the user supplied documentation
site, it would be easier to determine where the "official" turbine
documentation really need to be improved. We might even see a few
people in the community who are interested specifically in improving the
documentation make more progress in this area under this type of scheme.
A perfect example of this is how to use transactions. I am currently
migrating from 2.1 to 2.2rc1. When I wrote my code in 2.1 for
transactions, I had to go through the javadocs to figure out how to
accomplish the task. Not that it was very difficult but it would have
been nice if a "suggested method" for using transactions was documented
somewhere. In 2.2, the method for using transactions appears to have
changed.
I would not mind at all writing a small how-to on this little issue.
However, if the requirements for me to do this is to figure out some
specific format, I would be more prone to put it off until I have more
time to dedicate to it.
On Tue, 2002-11-12 at 09:46, Mitch Christensen wrote:
> I suspect we are using Anakia for generation of the Turbine site. If so,
> any documentation must be formatted in XML, per the Anakia requirements.
> Can someone validate this?
>
> What is mechanism for submission? If I write what I believe to be a
> beneficial howto, who decides that it has applicability, and incorporates it
> into the Anakia tree and regenerates the site?
>
> Could it be that lack of a formal process in the reason there is
> insufficient/outdated documentation?
>
> -Mitch
>
> -----Original Message-----
> From: Quinton McCombs [mailto:qmccombs@nequalsone.com]
> Sent: Tuesday, November 12, 2002 7:30 AM
> To: Turbine Users List
> Subject: Re: Documentation (was: Re: Thanks)
>
>
> Another idea for documentation could be something similar to the Linux
> Documentation Project. This would allow documents of varying scope.
> For example a very small how-to could be on transactions.
>
> A much larger how-to could be on intake or extending the turbine schema.
>
>
> On Mon, 2002-11-11 at 18:37, Scott Eade wrote:
>
> > Great. For new documents we should aim for at least an outline before
> we
> > add them as works in progress. If you intend working on these through
> to a
> > level of semi-completion then you should look at the existing xdocs
> and use
> > that format (it is really very easy).
> >
> > I can't recall where the xdoc documentation resides, bit it is fairly
> easy
> > to follow an example - e.g.:
> >
> http://cvs.apache.org/viewcvs/jakarta-turbine-2/xdocs/howto/extend-user-
> howt
> > o.xml?rev=1.7&content-type=text/vnd.viewcvs-markup
> >
> > Cheers,
> >
> > Scott
>
> >Quinton McCombs<
> Strategic Planner, NEqualsOne
> 1800 International Park Drive
> Suite 205
> Birmingham, AL 35243
> p: 205.324.8005 x121 800.466.1337
> f: 205.324.7008
> e: qmccombs@NEqualsOne.com
> www.NEqualsOne.com
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>Quinton McCombs<
Strategic Planner, NEqualsOne
1800 International Park Drive
Suite 205
Birmingham, AL 35243
p: 205.324.8005 x121 800.466.1337
f: 205.324.7008
e: qmccombs@NEqualsOne.com
www.NEqualsOne.com
Re: Documentation (was: Re: Thanks)
Posted by Scott Eade <se...@backstagetech.com.au>.
The process for updating documentation is exactly the same as updating the
source - i.e. create a patch issue in Scarab that contains the actual patch
to the documentation (the Turbine-2 Documentation module should be used).
Issues that are created in Scarab are reported to the turbine-dev mailing
list so that the committers are made aware of them and can commit or
otherwise comment on them.
As has been stated elsewhere, xdoc is a very simple format. You can follow
the lead of the existing documentation. I have also offered to format and
submit to Scarab documentation content suggestions posted to this list (as
did someone else).
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
> From: "Mitch Christensen" <mi...@informatixinc.com>
> Reply-To: "Turbine Users List" <tu...@jakarta.apache.org>
> Date: Tue, 12 Nov 2002 07:46:56 -0800
> To: "Turbine Users List" <tu...@jakarta.apache.org>
> Subject: RE: Documentation (was: Re: Thanks)
>
> I suspect we are using Anakia for generation of the Turbine site. If so,
> any documentation must be formatted in XML, per the Anakia requirements.
> Can someone validate this?
>
> What is mechanism for submission? If I write what I believe to be a
> beneficial howto, who decides that it has applicability, and incorporates it
> into the Anakia tree and regenerates the site?
>
> Could it be that lack of a formal process in the reason there is
> insufficient/outdated documentation?
>
> -Mitch
>
> -----Original Message-----
> From: Quinton McCombs [mailto:qmccombs@nequalsone.com]
> Sent: Tuesday, November 12, 2002 7:30 AM
> To: Turbine Users List
> Subject: Re: Documentation (was: Re: Thanks)
>
>
> Another idea for documentation could be something similar to the Linux
> Documentation Project. This would allow documents of varying scope.
> For example a very small how-to could be on transactions.
>
> A much larger how-to could be on intake or extending the turbine schema.
>
>
> On Mon, 2002-11-11 at 18:37, Scott Eade wrote:
>
>> Great. For new documents we should aim for at least an outline before
> we
>> add them as works in progress. If you intend working on these through
> to a
>> level of semi-completion then you should look at the existing xdocs
> and use
>> that format (it is really very easy).
>>
>> I can't recall where the xdoc documentation resides, bit it is fairly
> easy
>> to follow an example - e.g.:
>>
> http://cvs.apache.org/viewcvs/jakarta-turbine-2/xdocs/howto/extend-user-
> howt
>> o.xml?rev=1.7&content-type=text/vnd.viewcvs-markup
>>
>> Cheers,
>>
>> Scott
>
>> Quinton McCombs<
> Strategic Planner, NEqualsOne
> 1800 International Park Drive
> Suite 205
> Birmingham, AL 35243
> p: 205.324.8005 x121 800.466.1337
> f: 205.324.7008
> e: qmccombs@NEqualsOne.com
> www.NEqualsOne.com
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Documentation (was: Re: Thanks)
Posted by Mitch Christensen <mi...@informatixinc.com>.
I suspect we are using Anakia for generation of the Turbine site. If so,
any documentation must be formatted in XML, per the Anakia requirements.
Can someone validate this?
What is mechanism for submission? If I write what I believe to be a
beneficial howto, who decides that it has applicability, and incorporates it
into the Anakia tree and regenerates the site?
Could it be that lack of a formal process in the reason there is
insufficient/outdated documentation?
-Mitch
-----Original Message-----
From: Quinton McCombs [mailto:qmccombs@nequalsone.com]
Sent: Tuesday, November 12, 2002 7:30 AM
To: Turbine Users List
Subject: Re: Documentation (was: Re: Thanks)
Another idea for documentation could be something similar to the Linux
Documentation Project. This would allow documents of varying scope.
For example a very small how-to could be on transactions.
A much larger how-to could be on intake or extending the turbine schema.
On Mon, 2002-11-11 at 18:37, Scott Eade wrote:
> Great. For new documents we should aim for at least an outline before
we
> add them as works in progress. If you intend working on these through
to a
> level of semi-completion then you should look at the existing xdocs
and use
> that format (it is really very easy).
>
> I can't recall where the xdoc documentation resides, bit it is fairly
easy
> to follow an example - e.g.:
>
http://cvs.apache.org/viewcvs/jakarta-turbine-2/xdocs/howto/extend-user-
howt
> o.xml?rev=1.7&content-type=text/vnd.viewcvs-markup
>
> Cheers,
>
> Scott
>Quinton McCombs<
Strategic Planner, NEqualsOne
1800 International Park Drive
Suite 205
Birmingham, AL 35243
p: 205.324.8005 x121 800.466.1337
f: 205.324.7008
e: qmccombs@NEqualsOne.com
www.NEqualsOne.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Documentation (was: Re: Thanks)
Posted by Scott Eade <se...@backstagetech.com.au>.
> From: "Chris K Chew" <ch...@fenetics.com>
>
> The most current outlines can be found at:
> http://www.fenetics.com/turbine/index.html
>
This is going to be a PITA to keep up to date.
I think we really need is a twiki. I recall seeing something on the
maven-user list about an easily way to add a twiki to a maven based project.
I will see if I can dig this up and try and organise something.
A twiki is an ideal whiteboard for developing documentation. As the
documentation evolves we can decide if a document should remain on the twiki
or of it should be reformatted to become a document on the turbine site
itself.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Documentation (was: Re: Thanks)
Posted by Chris K Chew <ch...@fenetics.com>.
The standard combination of a Tutorial, (more thorough) User's Guide, and a
Developer's Guide would work well for Turbine. It would definitely be nice
to have more consistency in the documentation. Quinton made the suggestion
earlier that something like the LDP would also be nice. Really, I have
always considered the LDP to be a huge volume with each howto as a chapter
or sub-chapter. In that case the two ideas are the same when we consider a
howto as a section of the User's Guide or Developers Guide.
Unless there are objections, I will begin a new thread for each guide that
will work as a "whiteboard" for the outlines of the guides. I will also
maintain the latest version of the outlines on a web page behind my
company's domain. I figure that after we have an outline we can get
volunteers for sections, then assign general editors to smooth the edges.
The initial outlines are simple and missing much, this is because I am only
trying to start the conversation and not force its direction.
The most current outlines can be found at:
http://www.fenetics.com/turbine/index.html
Thanks for the help,
Chris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Documentation (was: Re: Thanks)
Posted by Quinton McCombs <qm...@nequalsone.com>.
Another idea for documentation could be something similar to the Linux
Documentation Project. This would allow documents of varying scope.
For example a very small how-to could be on transactions.
A much larger how-to could be on intake or extending the turbine schema.
On Mon, 2002-11-11 at 18:37, Scott Eade wrote:
> Great. For new documents we should aim for at least an outline before we
> add them as works in progress. If you intend working on these through to a
> level of semi-completion then you should look at the existing xdocs and use
> that format (it is really very easy).
>
> I can't recall where the xdoc documentation resides, bit it is fairly easy
> to follow an example - e.g.:
> http://cvs.apache.org/viewcvs/jakarta-turbine-2/xdocs/howto/extend-user-howt
> o.xml?rev=1.7&content-type=text/vnd.viewcvs-markup
>
> Cheers,
>
> Scott
>Quinton McCombs<
Strategic Planner, NEqualsOne
1800 International Park Drive
Suite 205
Birmingham, AL 35243
p: 205.324.8005 x121 800.466.1337
f: 205.324.7008
e: qmccombs@NEqualsOne.com
www.NEqualsOne.com
Re: Documentation (was: Re: Thanks)
Posted by Scott Eade <se...@backstagetech.com.au>.
Great. For new documents we should aim for at least an outline before we
add them as works in progress. If you intend working on these through to a
level of semi-completion then you should look at the existing xdocs and use
that format (it is really very easy).
I can't recall where the xdoc documentation resides, bit it is fairly easy
to follow an example - e.g.:
http://cvs.apache.org/viewcvs/jakarta-turbine-2/xdocs/howto/extend-user-howt
o.xml?rev=1.7&content-type=text/vnd.viewcvs-markup
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
> From: "Chris K Chew" <ch...@fenetics.com>
> Reply-To: "Turbine Users List" <tu...@jakarta.apache.org>
> Date: Mon, 11 Nov 2002 17:18:11 -0700
> To: "Turbine Users List" <tu...@jakarta.apache.org>
> Subject: RE: Documentation (was: Re: Thanks)
>
> I have thought of three guides to write, but am not sure if they would be
> helpful, or which to do first. Any suggestions?
>
> * Multiple Site Howto -- How to organize classes and actions so that a
> single turbine instance can serve multiple sites that may need to share
> common functionality
> * Service Howto/Introduction -- What services are, why they are nice, and
> how to write them
> * Non TDK Howto -- I found the TDK confusing because it did a bunch of stuff
> that I didn't necessarily want. So I learned about Turbine by removing
> everything, and putting it back in as I needed it. This document would be a
> "tour" in the form of setting up an example app without using the TDK.
>
> Thanks,
>
> Chris
>
>> -----Original Message-----
>> From: Scott Eade [mailto:seade@backstagetech.com.au]
>> Sent: Monday, November 11, 2002 5:03 PM
>> To: turbine-user
>> Subject: Documentation (was: Re: Thanks)
>>
>>
>> I had planned to conduct a review of the t2.2 documentation to
>> come up with
>> a list of things that need to be done to bring things up to scratch.
>> Unfortunately I am just too snowed under at the present to get to this.
>>
>> I would be surprised (somewhat pleasantly) if someone steps
>> forward to take
>> up the challenge of bringing the documentation up-to-date. There are also
>> other issues that need to be considered, in particular I don't believe the
>> steps involved in extending the turbine schema have even been fully
>> developed (anecdotal evidence indicates that several users have attempted
>> this to varying degrees of success).
>>
>> I think the best improvement we can hope for in the short term is for
>> specific incremental enhancements to existing documents to correct errors
>> and omissions. These could be posted to the list or better still
>> posted as
>> patches to the existing xdoc files. Updating the xdocs and producing the
>> patches can be a little intimidating at first, but it is pretty simple. I
>> am happy to process documentation suggestions from email through
>> to patches,
>> so if you want you can post a message to the list something like:
>>
>> The ultimate solution to my problem was ... My life would have
>> been much easier if the ... document included the following text
>> just above/just below/replacing ...
>>
>> ... New or replacement text ...
>>
>> I don't think we can expect someone to just step forward and solve this
>> problem. We ALL need to make contributions to achieve the
>> desired outcome.
>>
>> I am not complaining about your rant, but if you could direct a similar
>> amount of energy to providing a small update to the existing documentation
>> that covered the issue at hand then we would be on our way.
>>
>> Documentation patches are welcome. I will also try and assist by
>> processing
>> documentation suggestions contained in email messages through to patches.
>>
>> Cheers,
>>
>> Scott
>> --
>> Scott Eade
>> Backstage Technologies Pty. Ltd.
>> http://www.backstagetech.com.au
>>
>>
>>> From: "Mitch Christensen" <mi...@informatixinc.com>
>>> Reply-To: "Turbine Users List" <tu...@jakarta.apache.org>
>>> Date: Mon, 11 Nov 2002 15:36:44 -0800
>>> To: <tu...@jakarta.apache.org>
>>> Subject: FW: Thanks
>>>
>>> A lot of people are pulling out a lot of hair over Turbine.
>> Turbine is a
>>> great framework that *needs* to exist (I can find no reasonable
>>> alternative). Unfortunately, it is so poorly documented that many folks
>>> simply walk away after struggling with it.
>>>
>>> You can measure this by the number of "Hi, I'm trying to get
>> Turbine working
>>> but I keep getting an XXX error..." postings that come across,
>> and the user
>>> is never to be heard from again.
>>>
>>> Isn't there anyone out there that can spend a little time
>> cleaning up the
>>> documentation for Turbine?
>>>
>>> Right now, what Turbine needs is documentation, not new
>> features. If anyone
>>> has attempted to extend the turbine schema in any way, or use Intake for
>>> that matter. They quickly realize that it can be an exercise in
>>> frustration, admittedly offset somewhat by the elation you feel when you
>>> finally figure out (after days of searching) what could have
>> been documented
>>> in a couple of hours.
>>>
>>> I'm not being critical, it's just that I sympathize with Bill.
>>>
>>> The bottom line is that I believe that Turbine should be
>> amassing a larger
>>> user audience than it has (based on posting volumes to this
>> group), and I'm
>>> not sure how much longer Turbine can survive without legitimate
>>> documentation. (And I really think Turbine should survive)
>>>
>>> Sorry for the rant.
>>>
>>> -Mitch
>>>
>>> -----Original Message-----
>>> From: Bill [mailto:bhalpin@collaborativefusion.com]
>>> Sent: Monday, November 11, 2002 9:46 AM
>>> To: mitch.christensen@informatixinc.com
>>> Subject: Thanks
>>>
>>>
>>> The TRP.action.login option was totally the problem!!!! Thank you so
>>> much, I've been pulling my hair out over this. :)
>>>
>>> -b
>>>
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: Documentation (was: Re: Thanks)
Posted by Rodney Schneider <ro...@actf.com.au>.
On Tue, 12 Nov 2002 22:16, you wrote:
> Out of the three choices that you offer I'd be most interested in these:
> > * Service Howto/Introduction -- What services are, why they are nice, and
> > how to write them
>
> Especially how to port a Turbine-based service into a Fulcrum-based
> service.
Hi,
I think this should wait for a little while. Fulcrum is currently moving
over to being based on Avalon. See this post for more information:
http://archives.apache.org/eyebrowse/ReadMsg?listName=turbine-dev@jakarta.apache.org&msgNo=12183
Also, you can search the turbine-dev list for "Avalon" if you want even more
info.
Regards,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: Documentation (was: Re: Thanks)
Posted by Marc Lustig <ma...@marclustig.com>.
Out of the three choices that you offer I'd be most interested in these:
> * Service Howto/Introduction -- What services are, why they are nice, and
> how to write them
Especially how to port a Turbine-based service into a Fulcrum-based service.
> * Non TDK Howto -- I found the TDK confusing because it did a
> bunch of stuff
> that I didn't necessarily want. So I learned about Turbine by removing
> everything, and putting it back in as I needed it. This document
> would be a
> "tour" in the form of setting up an example app without using the TDK.
Marc
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Documentation (was: Re: Thanks)
Posted by Chris K Chew <ch...@fenetics.com>.
I have thought of three guides to write, but am not sure if they would be
helpful, or which to do first. Any suggestions?
* Multiple Site Howto -- How to organize classes and actions so that a
single turbine instance can serve multiple sites that may need to share
common functionality
* Service Howto/Introduction -- What services are, why they are nice, and
how to write them
* Non TDK Howto -- I found the TDK confusing because it did a bunch of stuff
that I didn't necessarily want. So I learned about Turbine by removing
everything, and putting it back in as I needed it. This document would be a
"tour" in the form of setting up an example app without using the TDK.
Thanks,
Chris
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Monday, November 11, 2002 5:03 PM
> To: turbine-user
> Subject: Documentation (was: Re: Thanks)
>
>
> I had planned to conduct a review of the t2.2 documentation to
> come up with
> a list of things that need to be done to bring things up to scratch.
> Unfortunately I am just too snowed under at the present to get to this.
>
> I would be surprised (somewhat pleasantly) if someone steps
> forward to take
> up the challenge of bringing the documentation up-to-date. There are also
> other issues that need to be considered, in particular I don't believe the
> steps involved in extending the turbine schema have even been fully
> developed (anecdotal evidence indicates that several users have attempted
> this to varying degrees of success).
>
> I think the best improvement we can hope for in the short term is for
> specific incremental enhancements to existing documents to correct errors
> and omissions. These could be posted to the list or better still
> posted as
> patches to the existing xdoc files. Updating the xdocs and producing the
> patches can be a little intimidating at first, but it is pretty simple. I
> am happy to process documentation suggestions from email through
> to patches,
> so if you want you can post a message to the list something like:
>
> The ultimate solution to my problem was ... My life would have
> been much easier if the ... document included the following text
> just above/just below/replacing ...
>
> ... New or replacement text ...
>
> I don't think we can expect someone to just step forward and solve this
> problem. We ALL need to make contributions to achieve the
> desired outcome.
>
> I am not complaining about your rant, but if you could direct a similar
> amount of energy to providing a small update to the existing documentation
> that covered the issue at hand then we would be on our way.
>
> Documentation patches are welcome. I will also try and assist by
> processing
> documentation suggestions contained in email messages through to patches.
>
> Cheers,
>
> Scott
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
>
> > From: "Mitch Christensen" <mi...@informatixinc.com>
> > Reply-To: "Turbine Users List" <tu...@jakarta.apache.org>
> > Date: Mon, 11 Nov 2002 15:36:44 -0800
> > To: <tu...@jakarta.apache.org>
> > Subject: FW: Thanks
> >
> > A lot of people are pulling out a lot of hair over Turbine.
> Turbine is a
> > great framework that *needs* to exist (I can find no reasonable
> > alternative). Unfortunately, it is so poorly documented that many folks
> > simply walk away after struggling with it.
> >
> > You can measure this by the number of "Hi, I'm trying to get
> Turbine working
> > but I keep getting an XXX error..." postings that come across,
> and the user
> > is never to be heard from again.
> >
> > Isn't there anyone out there that can spend a little time
> cleaning up the
> > documentation for Turbine?
> >
> > Right now, what Turbine needs is documentation, not new
> features. If anyone
> > has attempted to extend the turbine schema in any way, or use Intake for
> > that matter. They quickly realize that it can be an exercise in
> > frustration, admittedly offset somewhat by the elation you feel when you
> > finally figure out (after days of searching) what could have
> been documented
> > in a couple of hours.
> >
> > I'm not being critical, it's just that I sympathize with Bill.
> >
> > The bottom line is that I believe that Turbine should be
> amassing a larger
> > user audience than it has (based on posting volumes to this
> group), and I'm
> > not sure how much longer Turbine can survive without legitimate
> > documentation. (And I really think Turbine should survive)
> >
> > Sorry for the rant.
> >
> > -Mitch
> >
> > -----Original Message-----
> > From: Bill [mailto:bhalpin@collaborativefusion.com]
> > Sent: Monday, November 11, 2002 9:46 AM
> > To: mitch.christensen@informatixinc.com
> > Subject: Thanks
> >
> >
> > The TRP.action.login option was totally the problem!!!! Thank you so
> > much, I've been pulling my hair out over this. :)
> >
> > -b
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Documentation (was: Re: Thanks)
Posted by Scott Eade <se...@backstagetech.com.au>.
I had planned to conduct a review of the t2.2 documentation to come up with
a list of things that need to be done to bring things up to scratch.
Unfortunately I am just too snowed under at the present to get to this.
I would be surprised (somewhat pleasantly) if someone steps forward to take
up the challenge of bringing the documentation up-to-date. There are also
other issues that need to be considered, in particular I don't believe the
steps involved in extending the turbine schema have even been fully
developed (anecdotal evidence indicates that several users have attempted
this to varying degrees of success).
I think the best improvement we can hope for in the short term is for
specific incremental enhancements to existing documents to correct errors
and omissions. These could be posted to the list or better still posted as
patches to the existing xdoc files. Updating the xdocs and producing the
patches can be a little intimidating at first, but it is pretty simple. I
am happy to process documentation suggestions from email through to patches,
so if you want you can post a message to the list something like:
The ultimate solution to my problem was ... My life would have
been much easier if the ... document included the following text
just above/just below/replacing ...
... New or replacement text ...
I don't think we can expect someone to just step forward and solve this
problem. We ALL need to make contributions to achieve the desired outcome.
I am not complaining about your rant, but if you could direct a similar
amount of energy to providing a small update to the existing documentation
that covered the issue at hand then we would be on our way.
Documentation patches are welcome. I will also try and assist by processing
documentation suggestions contained in email messages through to patches.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
> From: "Mitch Christensen" <mi...@informatixinc.com>
> Reply-To: "Turbine Users List" <tu...@jakarta.apache.org>
> Date: Mon, 11 Nov 2002 15:36:44 -0800
> To: <tu...@jakarta.apache.org>
> Subject: FW: Thanks
>
> A lot of people are pulling out a lot of hair over Turbine. Turbine is a
> great framework that *needs* to exist (I can find no reasonable
> alternative). Unfortunately, it is so poorly documented that many folks
> simply walk away after struggling with it.
>
> You can measure this by the number of "Hi, I'm trying to get Turbine working
> but I keep getting an XXX error..." postings that come across, and the user
> is never to be heard from again.
>
> Isn't there anyone out there that can spend a little time cleaning up the
> documentation for Turbine?
>
> Right now, what Turbine needs is documentation, not new features. If anyone
> has attempted to extend the turbine schema in any way, or use Intake for
> that matter. They quickly realize that it can be an exercise in
> frustration, admittedly offset somewhat by the elation you feel when you
> finally figure out (after days of searching) what could have been documented
> in a couple of hours.
>
> I'm not being critical, it's just that I sympathize with Bill.
>
> The bottom line is that I believe that Turbine should be amassing a larger
> user audience than it has (based on posting volumes to this group), and I'm
> not sure how much longer Turbine can survive without legitimate
> documentation. (And I really think Turbine should survive)
>
> Sorry for the rant.
>
> -Mitch
>
> -----Original Message-----
> From: Bill [mailto:bhalpin@collaborativefusion.com]
> Sent: Monday, November 11, 2002 9:46 AM
> To: mitch.christensen@informatixinc.com
> Subject: Thanks
>
>
> The TRP.action.login option was totally the problem!!!! Thank you so
> much, I've been pulling my hair out over this. :)
>
> -b
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>