At 12:56 AM 10/4/2002 +0200, Laurens M. Fridael wrote:
>From: "Fringe Ryder" <[EMAIL PROTECTED]>
> > So PLEASE let's handicap them and choose one. ANY one. I don't care as
> > long as it's likely to have legs. To me that probably means C++, then
> > Java, then Perl, and least likely Python, but obviously I've been working
> > on the Python and wouldn't mind continuing that either.
>
>I believe in diversity and giving people a choice. As every programmer has
>his/her favorite language for writing applications, it's only a Good Thing
>that multiple solutions for Plucker content creation exist. That way they
>will be able to create more tools. The more tools we give to users, the more
>content they will be able to create, and the more Plucker will be adopted. I
>think the Viewer deserves it, and Palm users deserve the Viewer.
and at the same level,
At 05:48 PM 10/3/2002 -0400, David A. Desrosiers wrote:
> I disagree. The more languages we can use to extend it, the better
>off it will be, when it comes time to integrate Plucker into devices like
>the Zaurus, iPAQ, Palm OS5 devices, and so on. Besides, the spidering and
>parsing of a simple config file is pretty trivial, once you figure out all
>the precedence of elements you need to parse, and for that, we have docs.
>
> We shouldn't agree on the language, we should agree on the syntax.
Apparently I'm alone in my opinion. Okay, here's why I'm asking...
I won't be involved with Plucker actively for the long-term probably. I'm
likely to add the features I care about (and yes, I'm aware of
Pluck-Comics, but I believe the control I want should be at the spider
level and integrated to the tool), but I'm in a year I'll probably be a
happy user of the resulting product.
With four or more different parser/spiders, they will have feature
divergence at some point. Just as a minor example, we already have two
distinct Python spiders because Robert is distributing my changes adding
--stayondomain but Bill hasn't inserted it into his area of cvs, and it
probably hasn't been propagated into the Java parser and certainly not the
older Perl parser. But --stayondomain support was -already- in the Plucker
Desktop and documented in the help long before I ever heard of Plucker.
That means we -can't- agree on the "syntax"... we can't even get changes
propagated into a single platform. (e.g. Python in this case.)
Now if y'all consider that to be the normal-and-acceptable cost of the way
you want things done, I'm fine with it. At that point, I will probably
adopt a specific codebase - perhaps the Python, perhaps a C++ rewrite - and
work on improving it for Plucker Desktop integration without concern as to
the larger community. I guess it's just a philosophical question - do
y'all want to have a well-defined and well-implemented Plucker or a variety
of roughly-Plucker-like implementations that each require their own
documentation?
Tony McNamara
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
