In article <952uab$18q$[EMAIL PROTECTED]>, "Mark Hammond"
<[EMAIL PROTECTED]> wrote:
> In article <950n6f$[EMAIL PROTECTED]>,
> "Braden McDaniel" <[EMAIL PROTECTED]> wrote:
>
>> Contrary to your implication here, I didn't "declare" anything "not
>> interesting" without qualification. Whether you care to acknowledge it
>> or not, lots of developers won't change course and start working on
>> making XPCOM usable to them just because they could use some of the
>> functionality it provides. They would prefer to work on their own
>> project, even to the point of creating a customized solution, rather
>> than face the XPCOM learning curve *and* have to deal with making it
>> functional for their needs.
>
> Fine. I doubt anyone will miss them!
Such exclusive attitudes as this are the problem. (And, yes, a failure
to behave inclusively here *is* exclusive.)
>> Okay, Mark: what's *your* plan for dealing with dependency on XPCOM? If
>> it's "make our users install all of Mozilla" or
>> "ship a specialized version of XPCOM with our app", then
>
> First, the plan is to get our app to a state where we are happy to call
> it a V1. Then, we roll out sleves up and move towards the second stated
> option - except I personally have found the Mozilla guys very helpful,
> and very keen to accept high-quality patches - so it wont be "a
> specialized version of XPCOM", but will include the contributions we
> make back to XPCOM, and then available for all.
Regardless of what circuit your changes make, you're including a
specialized version of XPCOM if your app (and any of your app's clients)
are the only things that depend on the version of XPCOM you install.
And a critical point of these recent threads is, that's *lame*. Many
developers will simply go elsewhere when faced with such lameness.
>> >> There are lots of projects out there that need similar solutions to
>> >> some of the problems that Mozilla is solving, and they aren't
>> >> necessarily Web browsers.
>> >
>> > Yep - and many of them are working with xpcom today!
>>
>> Are you deliberately dismissing the fact that many of them are not, or
>> are you genuinely unaware of this factoid?
>
> The same is true for _many_ technologies. What is your point here? Are
> you suggesting that everyone with similar goals must use XPCOM, or it
> has failed?
I'm saying that if a bunch of techniques arise to fill the same role as
XPCOM, simply because XPCOM is too tightly coupled to the Mozilla
browser, then XPCOM has failed.
> But more to the point, as you taking it upon yourself to speak for all
> these companies?
No. I simply have a theory as to why more people aren't using it; a
theory that's supported by comments from some developers on these
newsgroups.
> We have no idea why they chose not to use XPCOM, so we
> should let them speak for themsleves.
Some of them are. Some of them probably don't care enough. I'm of the
opinion that many in that latter group *would* care if XPCOM were a bit
more accessible.
> You have made your position crystal
> clear, but let others speak for themselves.
I'm neither speaking for anyone nor am I preventing anyone from
speaking. I'm speaking in favor of a need I perceive to exist.
>> > Dont forget to wave as they pass you by!
>>
>> Uh huh. XPCOM still loses. That's the point. Whether you or I am using
>> it is not.
>
> No - my point is that people _are_ using it, and I don't believe it will
> lose.
>
> I really dont know what you are getting at here. Some companies are
> starting to use XPCOM, and are contributing patches back. Others
> (realtively) silently decide to pass it by for their own good reasons
> (although I have no idea what they are replacing it with that is
> better!).
Let's see... You admit to having "no idea" what someone might be using
instead of XPCOM, but clearly people *are* using other things. Aren't
you the least bit curious what their reasons are? Wouldn't you like an
"idea"? Don't you think there's a good chance that XPCOM could benefit
from adding the functionality those developers perceive as missing?
Let them submit patches, you say? Well, let them eat cake! Such
dismissals are totally oblivious to the reasons any developer starts
contributing to a project in the first place. There is a minimum
threshold of utility and usability that must be met in order to for a
project to be attractive to prospective developers. That standard will be
different depending on the project and the prospective developer; and,
obviously, it is met for you. But to cavalierly dismiss anyone for whom
that standard has not been met is simply foolhardy.
I'm trying to focus on lowering barriers to contribution for libraries
that have a strong potential to see reuse in other projects. Responses
such as "Just contribute!" demonstrate ignorance of the problem, denial
of the problem's existence, or both.
> Then there seems to be a 3rd class of people who complain about it, and
> expect everyone to pitch in for them - when they should make one of the
> decisions above, and should they decide to go with it, roll their
> sleeves up and jump in.
Well, I'm firmly convinced of what the Right Solution is to one of the
accessibility problems. To date, the PTB have not agreed with me. The
disagreement is not entirely unreasonable, yet more than a year has
elapsed and the problem remains unsolved. I have already (privately)
expressed my willingness to help for a third time, but I won't help with
a solution that I don't think is the right one. I guess we'll see what
happens.
Braden
