I read this at
http://www.mcpressonline.com/[EMAIL PROTECTED]@.6b3a2624
The relevant portion of the message is
The Project
Well, the first opportunity to take a shot at this presented itself as
the result of a confluence of several events. First, I needed to write
an article about open-source CMS systems. Second, I wanted a
Web-enabled tool to help manage a current project, and the idea of a
wiki looked like a good fit.
In a previous article about installing an open-source CMS system, I
remarked that the installation went reasonably well despite the fact
that I had to hack the code a little bit. I also implied that my
ability to do the hacks was attributable to the time spent coding in
Java and that I'd probably not do nearly so well in other languages.
Well, let me tell you about Trac. Trac is a combination wiki and issue
tracking system, the perfect thing to help organize the issues that
come up in the course of a normal development project. The wiki portion
of the tool allows you to define terminology, organize design thoughts,
and share ideas about architectures, while the issue tracking part is
perfect for defining specific individual tasks, assigning them, and
tracking their progress. Together, these can provide some real help in
managing a project, particularly one that has high time pressures and
requires lots of triage; even lower priority ideas can be recorded in
the wiki, and for hot items, tickets can be added to the tracking
system that point directly to the wiki entry for that particular
feature (and vice versa). And it's all free! Sounds too good to be
true, doesn't it?
What Happened?
I'm glad you asked, because the answer is that you really do get what
you pay for. Let me just recount the issues. First, I had to identify
what all to download. And while the Trac Web site has some good
installation documentation, there are things that just don't happen
magically.
First example, I downloaded Apache. I got the latest and greatest
version, Version 2.2, and I installed it. Next I wanted to go get
Python. Python has two basic modes (as do many Apache plug-ins):
standard CGI calls to the Python interpreter, and the mod_python Apache
HTTP Server module that integrates directly into Apache and provides
much better performance ("much better" being code in the CGI world for
"acceptable" and usually what is required for production-level work). I
of course wanted the better-performing option, which led directly to
open-source roadblock number one. The mod_python module is incompatible
with Apache Version 2.2. So I had to go back to the Apache site and
download Version 2.0.59. Watch the daring systems integrator as he
performs his balancing act on the high wire! Will he go for the
features of the newer version of Apache or the superior performance of
mod_python? And how in the world does he decide? In fact, how did he
even figure out what mod_python was, anyway?
Research, that's how. Which translates to time. Time spent on the
Internet. Time spent reading documentation. Time spent scouring
newsgroups. Time spent trying various combinations to see what works.
And that was just two of the modules!
It gets more fun. Python, like most interpreted languages, talks to the
world with special hard-coded "bindings," which are typically
platform-specific modules used to call other applications. Trac wants
to use Subversion for version control. Unfortunately, in order to be
compatible with Version 2.0 of Apache, the Subversion bindings for
Python need to be compiled with Microsoft Visual C++ Version 6, which
is not compatible with the later version of the Microsoft compiler used
to compile Python Version 2.4. So the later version of Python that I
installed wouldn't work with the Subversion bindings. Oh joy.
There was a fix, though. After spending many hours just to figure out
what the problem was, I then spent a lot more hours researching the
fix, which was this: download the Subversion bindings for Python 2.3
and then, with a hex editor, go in and modify the half-dozen or so DLLs
that are part of the Subversion package, changing each instance of
Python23.dll to Python24.dll.
Was It Worth It?
Boy, I guess that really depends on what you mean by "worth it." For
me, I was happy to get the wiki up and running; it's already seeing
lots of use. I may eventually move to a different wiki product; there
are lots of them out there. But this one will also provide me with the
ability to earn my Python chops. So for me, yeah, it was probably worth
it.
But if my goal were to find an enterprise-ready, mission-critical
solution, I'd have to say this fails on a couple of counts, from
fragility to the sheer bulk of minutiae that I had to learn just to get
this far. I don't know how many people have the time to chase down
instructions for hex editing DLL files and even then how many would
install the patched programs into production.
So in the end, you do indeed get what you pay for, and in the case of
whether a given open-source package will work for you, just remember to
budget time-more time than you would spend on a typical System i
tool.
Joe Pluta is the founder and chief architect of Pluta Brothers Design,
Inc. He has been working in the field since the late 1970s and has made
a career of extending the IBM midrange, starting back in the days of
the IBM System/3. Joe has used WebSphere extensively, especially as the
base for PSC/400, the only product that can move your legacy systems to
the Web using simple green-screen commands. Joe is also the author of
E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and
WDSc: Step by Step. You can reach him at [EMAIL PROTECTED]
I was pissed with this and posted
There is a cost to using opensource. But then, Programming is a
commodity, and it is better to pay a programmer once to implement a
free solution than to pay huge fees year on year. Also, Trac is a well
respected package used by tens of thousands of projects - all of who
rave about how great it is. If this guy had hired a person who has
already climbed the learning curve, the implementation would have taken
about a tenth of the time and effort that it took this loser. Also, it
must be admitted that implementing OSS in a windows environment on the
serverside is a bit mad - the guys who wrote the programs
usually use Linux/unix/BSD and these tools are optimised for these
environments. It is a credit to the OSS coders that they work on
windows at all. How many native windows tools work on the *nix
platform? < 5%! . Of course, with the web as a medium, the
clients of all these programs work just fine with windows.
Is there any further response from the Trac community - or is there an
easy solution to the problem posed?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/trac-users
-~----------~----~----~----~------~----~------~--~---
