Re: Library naming
2004-08-02 09:52:45
On 2 Aug 2004, at 15:42, James Couzens wrote:
On Mon, 2004-08-02 at 02:26, Christian Brunschen wrote:
'libspf' isn't only the most generic name possible - it's also a name
that suggests a certain level of 'officialness' - i.e., the name
'libspf' doesn't just imply '_a_ library for spf' but also '_the_
library for spf'.
I'm not sure which rock you crawled out from behind,
Ah yes, a stellar example of common courtesy and a civil tongue.
but this is common
practise. Let me give you some examples:
C -> libc
originally, there was only one C language and one system on which the C
language was used - Unix, as published by AT&T. Since then, various
Unix-derived and Unix-like systems have branched or been independantly
developed - but within the context of each one, there has only been one
C library, 'libc', which has thus been generic within that OS context,
but specific outside it (because it is part of that specific OS and not
of the others, nor intended to be).
GNOME -> glibgnome
The project is called 'GNOME', not 'libgnome' - 'libgnome' is just the
name of the GNOME library that is produced as part of the GNOME
projects itself. GNOME is not a generic name for anything - it is a
specific name, being an acronym for 'GNU Network Object Model
Environment' IIRC. Also, there is only one GNOME project which entails
both the specification and the implementation as one whole. In
contrast, the SPF specification is one project, and there are several
different projects that implement libraries for working with SPF. Thus,
this is not a good example of what you are attempting to show.
XMMS -> libxmms
there is one XMMS project which entails both specification and
implementation, much like GNOME above, so again the parallel is not as
you suggest.
XML -> libxml
this one is a better example, but here it is well specified that
'libxml' is part of the GNOME project, and is not a stand-alone project
that claims to be the original and official XML handling library. I
consider 'libxml' and 'libxslt' badly named, and in fact an example of
something that one should *not* do.
CURL -> libcurl
'curl' is once more a specific project name - it deals with URLs, yes,
but 'libcurl' is not a generic name for anything that would handle
URLs.
TCL -> libtcl
Likewise, 'libtcl' is specific to 'tcl' (Tool Command Language) and is
not generic either.
PNG -> libpng
In the png project, there was a concerted effort to have one official
png library, as a reference implementation if you will. In contrast,
with SPF there are multiple different implementations, neither of which
is more official than any other.
Are you seeing a trend here?
Yes. Are you? The pattern being that in most examples above, there is
much less of a parallel to the current situation that you appear to
think. Only one of the examples actually parallels the SPF situation -
and there, the authors of libxml are being very clear that they are not
claiming libxml to be 'official' or 'the original' xml processing
library, but are part of a specific project (GNOME).
Listen. I'm going to be rather blunt here.
I'm not sure that 'blunt' is the right word.
I'm going to iterate some
real clear logic here thats common life everywhere.
FIRST COME, FIRST SERVED.
Such simplistic arguments are useful in some circumstances, but not in
all. Specifically, had you chosen a name that was easily
distinguishable as being yours as opposed to being a generic name, I
don't think the situation would have arisen. The generic name is
inherently more likely to be the subject of confusion, as others will -
like you - gravitate towards that generic name.
If you want a conflict-free situation, then you should use a name that
is inherently less conflict prone.
Or perhaps to phrase it in terms you seem to find easier to understand,
EASY COME, EASY GO.
I believe thats enough to reiterate my feeling of this situation. That
being said, please drop it.
In other words, you are going to stick to your opinion and are
uninterested in hearing any viewpoint that disagrees with yours. That
clears up a lot.
Re: libSPF, I don't need to, I should not
have to, and I am not going to rename it. Wayne has illustrated
perfectly to the entire community the cloth he is cut from. I have
done
the same.
Exactly: You claim to take the moral high ground, yet show that you are
really just being petty.
In my opinion, the name 'libspf' should not belong to someone who just
happened to grab it first (following you 'first come, first served'
policy); it should be reserved for a 'reference implementation' if
there ever is one. Your implementation, being the first one published,
is of course a candidate for being such a reference implementation, but
it should gain that name on its merits, not just by virtue of your
grabbing it first.
I've pissed off some of you with my harping, perhaps the sting will
subside. The rest of you, of whom business this is not, I apologize
for
raising the issue in a public place, my only goals were to raise
awareness through demands that he rename.
You demand that someone else rename, when you yourself are refusing to
do just that. I find that ... interesting. The 'first come, first
served' policy can be just as easily applied to 'libspf2' as to
'libspf', you know.
You complain that the similarity between the names 'libspf' and
'libspf2' causes confusion. Well, my complaint is that the name
'libspf' causes confusion as well, because it suggests that libspf is
in some way officially connected with the SPF specification - which it
isn't. It just one of several libraries that are implemented to offer
SPF processing facilities.
Now that said awareness has
been accomplished, and Wayne isn't going to Do the Right Thing (tm)
this
is done.
Well, neither are you Doing The Right Thing(TM), which would be to stop
claiming that your libspf is somehow official (which it isn't), and
relinquish the names libspf and libsrs to be available for actual
reference implementations once such are available - which might well
end up being your implementations in the end if they are good enough.
If you have questions regarding this, I will gladly discuss them off
list.
You have previously been very happy to discuss them on-list - why has
this changed?
Cheers,
Best wishes,
James
// Christian Brunschen
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Library naming, (continued)
- Re: Library naming, Michel Bouissou
- Re: Library naming, David Brodbeck
- Re: Library naming, James Couzens
- RE: Library naming, Michael R. Brumm
- Re: Library naming, Christian Brunschen
- Re: Library naming, James Couzens
- Re: Library naming,
Christian Brunschen <=
- Re: Library naming, James Couzens
- Re: Library naming, Christian Brunschen
- Library naming, Roger Moser
- Re: Library naming, Greg Connor
- I had hope (was: Re: Library naming), Marc Kool
- Re: Case Sensitivity, James Couzens
- RE: Case Sensitivity, Scott Kitterman
- Case Sensitivity, Roger Moser
- RE: Case Sensitivity, Michael R. Brumm
RE: Case Sensitivity, nospam
|
|
|