spf-discuss
[Top] [All Lists]

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>