1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices Coding] Services
5
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Services%205&In-Reply-To=">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"000007.html">
11 <LINK REL=
"Next" HREF=
"000017.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices Coding] Services
5</H1>
15 <B>Pinto, Joao luis (J.M.)
</B>
16 <A HREF=
"mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Services%205&In-Reply-To="
17 TITLE=
"[IRCServices Coding] Services 5">jpinto17 at visteon.com
19 <I>Fri Dec
14 03:
57:
50 PST
2001</I>
21 <LI>Previous message:
<A HREF=
"000007.html">[IRCServices Coding] Version
5.0 alpha release available
23 <LI>Next message:
<A HREF=
"000017.html">[IRCServices Coding] Version
5 (feature request)
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#16">[ date ]
</a>
27 <a href=
"thread.html#16">[ thread ]
</a>
28 <a href=
"subject.html#16">[ subject ]
</a>
29 <a href=
"author.html#16">[ author ]
</a>
34 <PRE>I hope other people don't know so much about ircservices as you know about
35 sourceforge. You probably wouldn't like to see your project named as
36 piece-of-shit-formerly-known-as-irc-services.
38 ><i>3) Not really, mostly because it would be a pain to set up and manage.
39 </I>><i>I may set something up once
5.0 has gone stable, but until then it's just
40 </I>><i>too much to deal with. And I want absolutely nothing to do with the
41 </I>><i>piece-of-shit-formerly-known-as-Sourceforge.
44 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">Lamego at PTlink.net
</A>
47 -----Original Message-----
48 From:
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org
</A> [mailto:
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org
</A>]
49 Sent:
14 December
2001 09:
44
50 To:
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">ircservices-coding at ircservices.za.net
</A>
51 Subject: Re: [IRCServices Coding] Services
5
54 Looks like this didn't get through the first time, so:
56 1) No, because I have no clue how many bugs will turn up ;) At this point
57 I'm tempted to say beta in February and stable release in April or so, but
58 I have absolutely no basis for saying that, so don't quote me on it.
60 2) The notice is intended more for lamers who say
"ooh it's version
5!
" and
61 rush to download it. Feel free to use it on your production network, as
62 long as you take responsibility for any problems it causes. There aren't
63 too many major issues right now that I can think of, but it's the ones I
64 haven't found yet that worry me more. (One major issue I do know of is
65 that rehashing modules.conf doesn't work yet and could easily break
68 3) Not really, mostly because it would be a pain to set up and manage.
69 I may set something up once
5.0 has gone stable, but until then it's just
70 too much to deal with. And I want absolutely nothing to do with the
71 piece-of-shit-formerly-known-as-Sourceforge.
73 4) For autojoin in particular, it was pointed out to me that not everyone
74 always accesses IRC from the same computer, which would make client
75 settings irrelevant. In general, though, with the module system, I'm a bit
76 more lenient in terms of what I'll let in, since you can just disable
77 modules you don't need. (And the reason for almost everything being
78 enabled in the default config is so you'll all test them for me. ;) Some
79 will probably be disabled in beta/final releases.)
82 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org
</A>
83 <A HREF=
"http://achurch.org/">http://achurch.org/
</A>
85 ><i>Firstly, thanks to Andrew for releasing the alpha version. Hopefully he
87 ><i>not feel that he has to later remove this opportunity.
89 </I>><i>A few early questions that maybe Andrew or the Alpha team might be able to
90 </I>><i>comment on.
92 </I>><i>1) Do we have any idea on time scale for development beyond alpha? I
93 </I>><i>understand that it is a difficult question to answer given RL committments
94 </I>><i>but based on work so far and this extended open test hopefully highlighting
95 </I>><i>major issues quite quickly, might make it easier to provide an estimate.
97 </I>><i>2) Despite the warning not to run the alpha on a production network, it
99 ><i>seem to be the best place to run it since it will give a much more
101 ><i>test of the code. It is also very tempting to upgrade :) To this end, are
102 </I>><i>there specific known issues at this time with the current build that would
103 </I>><i>make it completely impractical to run on a small production network? The
104 </I>><i>"knownbugs
" file does not seem to have anything specific to Services
5 and
105 </I>><i>nothing serious mentioned either way but those who have already had chance
106 </I>><i>to play with Services
5 may have a good idea of things that would make it
107 </I>><i>unsuitable for risking in a production environment.
109 </I>><i>3) At present we seem to be restricted to the mailing list for bug
111 ><i>and discussion which makes the process qyute closed. Has there been any
112 </I>><i>thought given to providing some kind of online tracking system which would
113 </I>><i>both show what bugs are currently known and their status? Maybe something
115 ><i>sourceforge or similar system would suffice.
117 </I>><i>4) I was wondering about the reasons for AJOIN being included in Services
119 ><i>It seems to place an overhead on NickServ that has been handled by many IRC
120 </I>><i>clients for a number of years. Even clients which do not specifically
121 </I>><i>support it, but that implement perform can easily provide AJOIN
122 </I>><i>functionality. Any client supporting scripting could easily manage an AJOIN
123 </I>><i>list. A number of clients support dynamic AJOIN lists by offering to
124 </I>><i>remember hannels that a user uses on a regular basis.
126 </I>><i>Since part of the ethos behind IRC Services development is not to perform
127 </I>><i>tasks that really belong in IRCd or in clients or could be scripted, it
128 </I>><i>seems odd that firstly this system has been implemented and secondly it is
129 </I>><i>enabled in a default configuration.
131 </I>><i>Is there something specific that I am missing about this services managed
132 </I>><i>auto join list which makes it preferable to the existing client code which
133 </I>><i>already performs this task?
136 </I>><i>Anyway, back to play around with the source some more.
140 </I>><i>------------------------------------------------------------------
141 </I>><i>To unsubscribe or change your subscription options, visit:
142 </I>><i><A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
</A>
143 </I>------------------------------------------------------------------
144 To unsubscribe or change your subscription options, visit:
145 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
</A>
153 <LI>Previous message:
<A HREF=
"000007.html">[IRCServices Coding] Version
5.0 alpha release available
155 <LI>Next message:
<A HREF=
"000017.html">[IRCServices Coding] Version
5 (feature request)
157 <LI> <B>Messages sorted by:
</B>
158 <a href=
"date.html#16">[ date ]
</a>
159 <a href=
"thread.html#16">[ thread ]
</a>
160 <a href=
"subject.html#16">[ subject ]
</a>
161 <a href=
"author.html#16">[ author ]
</a>
projects / irc.git / blob