> I think that maybe both of you misunderstood me :)
No, we both understand you completely, except...
> You can still use prc-tools to build a viewer that uses the font, the only
> thing you cannot do without codewarrior is alter the font itself :)
...this part. If someone wants to update the fonts, or change
anything related to the fonts, they can't. Let me make an analogy for you:
Let's say I'm working on a GPL (or LGPL) linux kernel driver for a
3Com Winmodem. It will only work with their proprietary DSP, which is in
"rendered" in software. They say I can provide the DSP, in software, as a
binary-only linked resource to the code I write. Easily done, since 3Com
doesn't want to release the specs for their DSP-in-software to the Free
Software community. Now let's say they retire that product, or someone wants
to enhance its features, or some other change. They can't, because they only
have a binary bit of code that does them no good. Nobody would use it (the
binary-only linked resource in a Free Software kernel module), and the
driver would die.
The issue here is that, although you can include it in the project
_in your own code_, it shouldn't be part of the upstream Plucker source, and
definately not shipped with any Plucker releases that we make.
One of the core goals, since the very beginning (before you joined
the team) was that _every_ single part of this project must be able to be
built on a "standard" Linux/Unix machine, using freely-available tools. If
there is some additional functionality that can only be brought into Plucker
with a binary-only interface, it limits the audience, and stomps on that
goal.
Here's another example: Let's say AvantGo approaches us, and wants
to partner with us, by providing access through Plucker to their "channel"
data, in a live conduit. Basically turning Plucker into an "online AvantGo
channel fetcher". They provide us with a binary-only resource which adds
this capability (Netlib, AGConnect, et al). Should we include it, even
though it would add a feature that can satisfy a lot of users? I'd say no,
and I'm fairly certain Mike and others would too.
> Either way, I'm not trying to avocate codewarrior or anything. It would
> probably be best just to keep it out of the equation altogether.
If CodeWarrior wants to play nice, have them open up the code to do
that part, or use your contacts at Palm/Palmsource to put pressure on them
to do it. Or, have Ben Combee talk to Aaron Ardiri and add the updates to
pilrc. Once it can be done with pilrc, there's no reason we can't add it.
d.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
