-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> My view is that JPluck and PlkrData are inherently Plucker related.
We definately agree, as is Fling-It, pler, OpenUrls, Plucker
Bookmark Assistant, and so on. The smaller defining line is that discussions
related to the usability of them, at a level deeper than peripheral ("When
click on File in JPluck, it crashes. Which JVM should I be using?") should
probably be directed to the forum dedicated to the support of that tool,
which generally isn't the same as the forum dedicated to supporting Plucker
itself.
I don't mind the discussion (and in fact, somewhat prefer it to be
"One Less Mailing List" I have to join), but when it gets into the
nitty-gritty of third-party development of these tools, it gets a bit
further away.
That being said, talking about how these tools work with Plucker is
certainly on-topic, but talking about how the tools THEMSELVES work,
probably is not. Again, I'm just one person, and I value the discussion, and
the fact that the tools are maturing so fast.
Maybe we should create separate lists for development issues of each
of these tools.. and let the "general" discussion about them continue on the
Plucker "general" list. I'm still not solid on my feeling about splitting
them off, but I can see the increase in topics that are closer to JPluck
than Plucker, and that's why I brought it up, thas'all.
> To me, PlkrData is really a part of Plucker in the same sense that the
> Python parser is, or that the Viewer is, in that it forms part of a useful
> suite of tools for configuring, Plucking, and then viewing Plucked data.
Correct, but Plucker cannot (currently) work without Python, as
distributed, so it is a core requirement, while JPluck replaces existing
functionality. If Plucker was simply the viewer, and nothing else, then
talking about the Python distiller (if it was shipped by Bill, separately
from Plucker [the viewer]), then it would be in the same category as JPluck
and PlkrData.
> And as pler. <g>
..and why discussions of pler happen off-list, and generally to me
directly (thanks to all that have helped out with that). If I had any
development issues related to pler, I would certainly create a separate list
for them though.
> This makes sense to me. I would be quite happy to handle bugs on a
> PlkrData mailing list and will try to nudge people that direction for
> those issues.
I'd be glad to maintain that list, if you wanted, or you could use
the ones on SourceForge.
I guess this is a good discussion for one reason... what happens
when there are 20+ third-party tools that work with Plucker? Someone just
mentioned recently making a Plucker Desktop for OSX? What about the perl
spider? PlerII? my.plkr.org? Ad infinitum. Maybe all of that discussion can
happen here. I'm ok with that, actually. Maybe I just saw an increase in
discussions related to the development and usability issues of JPluck, and
fired off the message that spawned this topic.
> IIRC, you were/are working on a perl spider (I could be wrong, and
> apologize if I got the details incorrect)... which is obviously not the
> Python distiller. The prevailing view was that the functionality was
> Plucker, not the actual implementation.
The perl spider/conduit, which actually existed before the Python
code was written by Holger a few years ago, will hopefully augment or
replace the Python distiller entirely. In my local tests, the perl spider is
5-7x faster than the Python code, and I can do a whole lot more with it,
thanks to the add-on modules from CPAN, such as reading/parsing PDF files,
Microsoft Word documents, XML and RDF formats, and so on. I can also easily
parallelize it, deal with cookies, etc. in only a small handful of lines of
code. It's very compact and fast.
That being said, as it matures, or becomes available, initially as a
"third-party" tool, I would expect that discussions about using it would
happen off-list, until it is either included in Plucker, or shipped as part
of Plucker. Maybe not though, there is still a lot of code to be (re)written
for it. I've also got to gut and rewrite pler a bit, so I can easily handle
accepting attached documents to convert (pilot.screwdriver.net is no longer
around, so I am going to replace that functionality with pler), and some
other things.
Also, I need to spend some time looking at PlkrData a bit, so I can
see what formats I need to digest for pler, the Perl spider, and for the
my.plkr.org/openurls portal on the platter here. This is why I was talking
about "flattening" our configuration file formats a few weeks/months back.
> That would indicate to me that JPluck is every bit as much Plucker as
> Plucker Desktop or Python distiller is.
Ah, but the defining diference there is that JPluck REPLACES
existing functionality that ships with Plucker. It doesn't provide something
that is required for Plucker to work. It's like a company that makes a drink
holder for your car. Would you expect that usability issues of that drink
holder happen on the Ford mailing list? Probably not.
> (I can't make that case for PlkrData, because it's new added functionality
> intended to help less-technical users leverage Plucker in any form it
> happens to be taking, including Python distiller, any
> distiller-INI-compatible form, and JPluck.)
I'm intrigued, but my plate is far too full to create time to look
into it. I'm sure it's a great tool overall (and maybe I can write a
POSIX-compatible version... in per =) Seriously though.. does this work on
non-Windows machines?
> I'm willing to believe that I managed to misunderstand and to draw
> inappropriate conclusions and extrapolations, but I assure you it was in
> good faith.
I'm sure there was no misunderstanding. I'm a purist by default, and
I prefer that Plucker discussions happen in the context of the Plucker list,
and discussions unrelated to Plucker (the viewer/distiller, i.e. the
components that ship with Plucker itself, and are required to use it) happen
on their own grounds. If those facilities aren't available (separate mailing
lists, for example), then perhaps that needs to be addressed.
> I don't believe that for a moment. The Dev list has had less than six
> messages a day this month, and the General less than nine messages a day.
A total of 183 messages so far on JPluck alone, actually.
> That's not a whole lot to "weed through", especially when the headers have
> been accurate. About a quarter of the messages on the General list were
> JPluck or PlkrData related, most in the last four days. I think it will
> die way down again quickly, just as Desktop created a slew of new messages
> for a week or so after a major release and then died down.
I think it will as well. I vote for either a list for third-party
stuff (plucker-thirdparty?) or keep it on-list, with defining subject lines.
Then again, I could just add few extra filters to procmail to rewrite these
headers a bit and stuff them into a separate folder. It's not a big deal.
> Of course off-topic posts can clog the waves quite a bit. For example,
> somebody recently posted a press release about Sybase acquiring AvantGo to
> the Plucker-Dev list. <evil grin>
Ah, true, except that was a one-off, and didn't generate 182
follow-up messages related to it =) If it got into a discussion about
AvantGo's financials, and not how this acquisition changes the
"competition", I would have recommended the discussion be taken off-list as
well.
> You've been exceptionally attentive to detail on your contexts, so my
> assumption is that the former context is the correct one, that being that
> the project is defined exclusively by accepted developers who arbitrarily
> define it.
Not at all, currently Plucker is a collection of tools that spider
and create files for installation onto your Palm handheld, which represent
textual/graphical data for display, either from web, local files, or other
document formats. Additional tools which leverage the use of Plucker, such
as pler, JPluck, and others, while interesting and beneficial to Plucker as
a whole, aren't part of Plucker itself. I suppose it's grey enough though,
so my vote is for a third-party tools list, where discussions of this type
can happen. Then again, that's another list, and fractures the discussion
even more. Let's keep it all on these lists for now, and just be clear in
the subject/other places that it is JPluck-development-related or whatever,
so it becomes easy at a glance to visually filter.
> That would exclude me, for example, because even though I have submitted
> both Python distiller (feature implementation and bug fixes) and Desktop
> C++ code that has been accepted into the tree, I have not been granted
> access to CVS.
Ah, but the problem with granting access to the cvs, is that it
would require the maintainer of that branch of the tree to value
$CONTRIBUTOR enough to ask that they be granted access. If I did that with
pilot-link, in exchange for actual valuable patches that I've committed, I'd
have over 100 people with cvs write access. That's probably not a good idea
to do, overall. Each branch has to be managed, governed by the direction of
the maintainer.
Patches from lots of people are worthwhile, if they solve a bug, add
a feature, or enhance functionality, as long as they don't break existing
functionality, or destabilize the application, but that doesn't mean that
the contributor should gain commit access to the cvs.
> If someone wants a new feature, they merely write it. Sure, it may not
> make it into the trunk, but it is still part of the "open source project"
> and can be posted as an available patch. When stuff diverges too far,
> there may be a schizm so that there can be another trunk supported by the
> people who wrote the features that were not put on the trunk.
Ah, but see above... how do you track the development of 10
different patches which all accomplish the same thing? Example: Matto has
contributed many fixes over the last couple of years. If someone else had
also create a different way to solve the same problem, using a different
approach, which do you accept to the tree? The "better" one? What if you
want to track both, or the development of both? 5 patches that allow
copy-to-clipboard, each of them maturing at their own rate. If you have 5
discussions here related to the copy-to-clipboard "patch", how does a user
know which one is which? And which one is the "right" (approved?) patch? It
can fracture very fast.. HOWEVER.. pointing to all 5 of them (maybe a FAQ
entry? or a monthly mailing of links?) and pointing to the developers or
lists associated with their maturation, would be less confusing to the
people who wished to test them.
Again, it can all happen on one list, but it needs to be clearly
discernable which is which. What parts do "we", the people who distribute
Plucker itself (viewer/distiller, in whatever language is appropriate) have
control over, and which parts are developed and maintained by others, in the
"third-party" space?
> It becomes confusing quickly. Most of my life is in the commercial world
> (obviously), where chains of control (and ownership) are very clear. In
> this case I think the problems may be a combination of:
Given this, maybe a quick rundown of what is what, and who does
what, either on the website, or on the list, which we can then point to
others to reference, would be ideal, or maybe an additional FAQ item.
> 1. Your expectations and ours weren't quite the same.
I should hope not. I certainly use Plucker in a MUCH different
fashion than most people, and that's the best part of the Open Source
development model.. many people use their own needs to jumpstart the
development of a different method to solve the same problem. You have,
Laurens has, Bill has, and each of us has.
> I figured PlkrData would add to Plucker and be considered a useful
> addition, eventually becoming part of the Plucker suite.
It is, and does (though I've never used it), but how many of these
things do we distribute as "Plucker"? What exactly is "Plucker"? To me, it's
a viewer, and the associated code to create the data that can be viewed
using that viewer. Tools that can convert the "channels" (create by a tool I
don't ever use, Plucker Desktop) wouldn't really be considered "Plucker" to
me, but maybe to others it is. Again, my purism leaks out, and I come from
the Unix community, where GUI, mouse, and other eye-candy elements actually
slow down the usefulness of the tool itself... TO ME. For others, YMMV.
> I made it trivial to translate and update specificially because I assume
> that I won't be controlling it.
I don't understand this. What exactly was confusing about the
"channel" format as it existed? I've got my problems with the amount of
"noise" that gets dumped into my nice clean ~/.pluckerrc file from Plucker
Desktop (and another reason I don't use it), but why did it need to be
converted? Were there elements missing? Were those missing bits communicated
to Robert?
Again, I don't know what PlkrData actually does, other than by
reading the default description on the news blurb, but why would I, a person
who uses Linux and Unix systems daily, use PlkrData? What does it leverage,
that Plucker itself does not? Perhaps this is another good idea for adding a
larger news article for PlkrData. "What exactly is PlkrData?". Care to write
one up? 2-5 paras would be good, if you can do that.
> So my expectation was it's more-or-less on trial before formally becoming
> part of the Plucker suite. I'm guessing your expectation is that new bits
> to be discussed on the board (at least in any volume) must first be
> approved by an internal board, but I'm not clear on that or if it's just
> the last three days' messages that have annoyed you.
There is no board (forum? message board? board of directors?) per
se, but I can see where you're coming from. Your intent is to write PlkrData
as a tool to hopefully include in the upstream distributed versions of
Plucker. What exactly does it do that Plucker doesn't? Does it convert
AvantGo "channels" to Plucker.ini-style data? I've missed a meeting on this,
I think (and obviously didn't read the messages related to it on the lists).
> There are regular clashes on email culture here too. The message last
> week from Ken Stuart on "Bad UI Design" demonstrated a culture-gap between
> commercial consumers and open source users.
My sarcastic message was only to try to encourage contribution. If
there's a problem with a tool that you use, or find useful, "wagging a
finger back and forth" isn't the best way to communicate that to the people
responsible for fixing the issue you've found. Providing a useful
"real-world" example of why it is broken, or sub-par, is definately much
better, and better still, is providing a patch which fixes that
functionality so that it addresses the concern.
I see this over and over and over again on the other OSS mailing
lists I'm on, where someone says that our tool(s) suck, and that we should
fix them, but they don't provide a patch, or in most cases, a real-world
example of why they think they suck. I'm all for helping out, but.. I'm a
volunteer on all of this, and if someone has a problem, I generally expect
that they've taken the steps to identify it, describe it, provide an
example, and (if they can) provide a fix. Most do not.
> (And that was about Desktop, incidentially. Is that Plucker or not?)
Yes, because Plucker Desktop *IS* "Plucker for Windows Users".
Without some sort of "installer" or way to create "channels" on Windows, the
Windows users would double-click on the Python interpretor and get nothing,
or double-click plucker-build.exe and get nothing. It eases the transition
from the Unix world, where Plucker was (and still is) developed, to the
users on Windows, who wish to use it. Formerly, Dirk Heiser had tools that
did this on Windows, but he has since disappeared, and nobody has heard from
him. Robert took it over, and created the wonderful GUI interface that
everyone on Windows uses now to get their content spidered. I contend that
without Plucker Desktop (for Windows users), the functionality of Plucker
would be "broken". That does not necessarily go for JPluck or PlkrData (as I
peripherally understand PlkrData that is). Plucker still works without
JPluck, and without PlkrData. They might enhance or replace parts of it, but
they do not add something that would be missing without it, that is
necessary for Plucker to function.
> In this case, asking us to use the SourceForge boards for more of the
> detail is a good start at re-educating us and nudging us in the right
> direction. Don't be upset that it's needed; at least people got involved,
> which is a huge win in today's society.
I've been mulling this over, and prior to my original message on
this topic was going to create a project in the bugtracker for both JPluck
and PlkrData, so users would be able to report bugs for each of them, in the
same bugtracker interface that they use to report bugs for Plucker, but then
I realized that SourceForge provides all of that already, as well as the
mailing lists, and forums, so I thought that it should be mentioned that
"development" issues regarding those two projects should probably use the
facilities designed to supporting those projects.
Tim Constantine was suggesting a "forum" type of interface back in
November, and SourceForge provides that. Maybe it belongs here, but the
project is over there. It gets a little confusing. Which list? Where do I
report bugs? Is the bug with JPluck? or with Plucker? etc. See the
confusion?
> Once it stops moving, the messages will probably drop to one a month like
> with other features.), but I think announcements about new versions still
> belong on the list.
We are in full agreement.
> The typical example, at least as apparent, was to announce new tools and
> features on the General and Dev lists. Given the presence of an Announce
> list, I've always wondered why, but I did precisely as you directed me to
> and followed example. Let's change it and set a new example, confining
> ALL announcements to the Announce list. Make sense?
I think part of that confusion may be that people don't know that
the announce list exists, and probably less know what it should be used for.
Mark, can you add a description on the Mailman interface for each
list that is on lists.rubberchicken.org? That would help considerably.
The messages sent there are moderated, and maybe more should get
through (though I don't know which ones are actually sent inbound). I'm also
open to creating a "plucker-thirdparty" or "plucker-external" type of list
for discussion of the "add-on" or "utility" tools that enhance the
usefulness of Plucker. That might clear up some confusion a bit, but then
again, that'll bounce between -list, -dev, and -external as well, as things
start to coalesce.
Let's leave it for now, I'm ok with things the way they are, but
when it gets "deep" into the issues related to the tool itself, those should
generally (not a hard and fast rule) be directed toward the project pages
and facilities for those respective projects.
d.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+BPNnkRQERnB1rkoRApuMAKCs+3NocVJGUJk50PGEhHguAu21HwCgydX5
vnqcGADjCiOczcq6kelmidQ=
=Sabu
-----END PGP SIGNATURE-----
_______________________________________________
plucker-list mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-list
