[IRCServices] I: service for ircu

[Kelmar K. Firesun]

----- Original Message -----
From: "Andrew Kempe" <andrewk at icon.co.za>
To: <ircservices at delirious.shadowfire.org>
Sent: Thursday, June 29, 2000 3:39 AM
Subject: Re: [IRCServices] I: service for ircu


] ... SNIP ... [

>
> IRC Services will ALWAYS be able to work with ircd's that it has supported
> in the past. However, those ircds may not be able to make full use of the
> features in IRC Services.
>
> I hope this makes you feel a lot more comfortable. As I've said in the
past,
> Services will always be RFC compatible.
>

Okay, that clears up quite a bit of confusion on my part.  Thanks for
letting me know.

>
> Hopefully in the future things will become a lot more modular. This should
> make it easier for a 3rd party development.
>

I would look forward to that.

----- Original Message -----
From: "Scott Seufert" <anarki at flamebait.org>
To: <ircservices at delirious.shadowfire.org>
Sent: Thursday, June 29, 2000 12:44 AM
Subject: Re: [IRCServices] I: service for ircu


] ... SNIP ... [

>
> I'm FAR from the decision maker as to what ircservices is and isn't
> capatible with. but I'd like to share a few pennies with you.
>
> First, is that ircservices are free of charge, meaning the coder(s) isn't
> getting paid a dime to code, and such code comes from kindness of heart,
not
> from requests from end users. Please don't confuse my last sentence to
mean
> that coders don't value end user input, they do, that's where alot of
ideas
> and bug fixes are spawned.
>
> It's MY opinion that the coder(s) should be allowed to go any direction
they
> wish and the end user should expect at least what the pay for.
>

As a coder I have always valued people's input about my programs.  But I
think
that with other peoples programs I should at least be able to state my
feelings
on how I think they could make a better product, free of charge or not.


>
> I am friends with several coders of services. Opus for OtherNet Services,
> Andrew Kempe, current maintainer of ircservices and I would like to count
> Andy Church in that group if I only got to know him more, seems that I
don't
> see him interact publicly as often. It seems that the majority opinion
from
> GPL coders in general is that their number one issue is that the end user
> isn't satisfied with what is given to them for free, they always want more
> and sometimes go as far as demanding more. I'm not saying nor implying
that
> you or anyone associated with yourself or your network is doing such, I'm
> saying basiclly you can't please everyone. CServe for OtherNet was pulled
> off of the GPL license with the release of CS6/UW9, Opus tried to sell the
> code he worked very hard on and nearly "gave" the project away, just to
rid
> of it. CServe/UWorld is unfortunately no longer available to the public.
GPL
> or for sale. Opus was pounded because the code wasn't public, so he made
it
> public with the GPL license, then he was pounded because it didn't meet
end
> users demands, so he tried to sell it, and was pounded 10 fold for trying
to
> sell it.
>

You are indeed correct sir.  But it wouldn't do Andrew, Andy, nor any of the
other coders/maintainers of the IRC services any good if they did not know
what others thought about the direction their programs would take.  GPL as
many will point out is free as in speech, not free as in beer.  What good is
it to them if their code is not used at all?

>
> I can't do anything shy of admire those that write/maintain GPL Services.
> They give and give without asking anything in return other than obey the
> license and to RTFM before asking for support, so why not let them deside
> what is supported and what isn't? So what if it's harder on a few end
users.
> To be blunt, most end users would be without services all together if it
> wasn't for the efforts of these coders. So lets concider how hard it is on
> the coders to do multidaemon support.
>

Indeed, I have always respected Andrew and Andy.  They have been doing an
excellent job at maintaining a widely used piece of code and keeping the
number
of bugs down, with out asking too much from anyone else around them.  I
recall
back on Esper when Andy would go several frustrating days coding services
trying
to get this and that working just so.  And yet, the code still comes out
neat,
readable and for the most part free of bugs.  Maintaining software is not an
easy choir.  I've run in to that problem with my own codings several times
in
the past.

> You also have the option to continue a multiple ircd services yourself or
> work closely with someone that maybe interested/knowledgeable in
> coding,ircservices is still GPL. So as long as GPL licensing is followed
you
> may spawn your own services off and continue that way. Please bear in mind
> if it wasn't for kind hearted GPL coders, you would most likely have to
buy
> or code services yourself. If you follow this course of action I wish you
> the best of luck. I hope you are prepared to deal with not only the
> headaches of coding, but countless hours of end user support, bug fixes,
> mailing lists, hundreds of emails both commending you and condemning you,
> visitors trafficing your channel on your net looking for support and/or
you
> to install services for them because they didn't RTFM. I wish you luck,
not
> only for the fact that I have no ill feelings toward one that tries to
make
> a difference, but I wish you luck because you WILL need it ...
>

Again, you are correct.  Because of the GPL I could port the services back
to
an older/different IRC daemon.  My problem with this is that with my own
daemon
in the works, I've found that I've had to devote much of my time to it
instead
of Services.  Push come to shove, I could have always used an older version
performing bug fixes as needed, but then I would lose some of the newer
features
of the up coming versions.  I used to know a good portion of the services
code
back when they were on 2.x and to a limited amount 3.x.  4.x has some
significant
changes in the way the message handling is done, and I'd have to sit down
and
figure it out, but this would just take some time, and I could be on my
marry way
performing changes.

>
> Secondly, if you pin point a specific IRCD type you can have it work even
> closer be it is only coded for said daemon, it would only have to support
> the commands from one type instead of many. This makes services smaller,
> faster and seemingly more seamless than multiple ircd support (which was
> Andy Church's original plan). That plan being to have good quality non
> bloated ircservices. I personally like one IRCD support, 99% performance
of
> one daemon to me is far more valuable than 80% performance on multiple
> daemon support.
>

Egh, to a limited extent.  Last time I looked, the code that's not needed
for
other IRCD's are blocked out with IFDEF's, so the only real time penalties
would
be with compiling.  The only thing that would be smaller to any great amount
would probably be the source code.

>
> What did I gain?
> I didn't have to write services myself
>

True enough.

>
> What did I loose?
> I had to use/switch the recommended daemon (which I didn't have to write
it
> either)
>
> Over all, I lost nothing.
>

Except for the point that I mentioned, which was stability on your network.
Granted my conceptions about the Bahamut code might be misplaced, they may
have made some significant improvements in that department sense I had last
used Bahamut; however, those are my experiences.

I would like to state two things though.  One) The message I did send was in
fect
very much my opinion, and a mis-interpretation on my part of Andrew's
original
message.  Two) I feel I might wish to apologize if that message seemed at
all
inflammatory, this was by far _NOT_ my intent in the slightest.  I was
merely
expressing a concern I had, I also had, nor do I, or will I have any
intentions
of "demanding" that the current maintainers of Services do anything that I
ask.
I haven't hired them, and I'm by far not their source of breed and butter.
If
something happens where I absolutely cannot use the code, then I will simply
write my own.  But why re-invent the wheel?

On the other hand, I think you confuse me with someone that constantly needs
assistance with getting services to just merely run and someone that assists
in maintaining the code.  While I do in fact run Services on my own network,
I have
also in the past (though not to any large extent) made suggestions,
comments,
and some code snippets in an effort to help make this program better.
Should
the need arise, and Andrew or Andy needed any additional help with coding,
that
I could provide them, I'm more than willing to do what I can.

In closing I would like to reiterate that this is an apology, and that I
have
no intention of starting a flame war.  (This is not an appropriate place for
such
things)  But I think we are both guilty of not looking before we leaped.

(Sorry about the long message folks)
Bryce Simonds
Kelmar K. Firesun


---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.