[dcc2] Comments

[codemstr at ptdprolog.net]

> The DCC2 draft specifically defines the DCC2 Send and Chat methods. I
> was referring to those not needing to be there. See section 4.3. I
> think the other instances are all examples.
Ok yes, I agree that should probably not be mentioned and instead should be 
mentioned in the respective drafts.

> I'm not doing any yelling ;) What I meant about "as-is" is that plain
> DCC Chat should simply be a client to client connection allowing for
> the exchange of text. 
Well if that's truly how you want it, then you don't want it "as-is" because 
DCC Chat already does more than that! It allows you to use CTCP ACTION. 
That's more than just "the exchange of text." If DCC Chat already uses CTCP, 
I don't see the harm in making it use CTCP a little bit more. 

> The suggestion
> was that the people who want all that extra junk in DCC Chat instead
> work on a separate draft for a separate application-type such as
> 'partyline'. I'll leave discussion of the dubious value for a
> partyline that is essentially an IRC server for another time...
But I'm not arguing for partyline, I'm arguing for nick changing. I don't 
want DCC Chat to include multiple users, kicking, invites, etc. All I want is 
nick changing. So what are you suggesting? You guys make draft-foo-dcc-chat 
and I need to make draft-bar-dcc-chat-nick because you think they should be 
seperate? For this one minor difference, you're saying we need two seperate 
protocols? I don't think anyone who responded to the CTCP control idea 
mentioned anything about using it for partyline. So I'm not sure where you 
got that idea from. We're talking about 1-2 minor features, not a full blown 
partyline. I'm telling you I want an apple, and you're telling me I need to 
go plant a seed and grow a tree. I don't want an apple tree, I just want one 
apple. Same here, I don't want a partyline, I just want a single feature that 
you seem to find characteristic of a partyline. 

> Well, the easiest way to provide that extra functionality is to design
> a protocol that doesn't start by assuming every line of text received
> is a line of text. Then you start having things that naturally follow,
> such as using PRIVMSG to send text, NICK to send a nick change, and
> numerics to report errors etc. you're already well on your way. But
> the IRCD comment was not directed solely at the CTCPs to provide
> commands bit, it was also aimed towards the 'multi-user chat' people
> and some of the other suggestions I've read or skimmed. I don't have
> anything constructive to say about their conversations since I don't
> agree with them, I'm just suggesting that they be separate projects
> because not only does it make more sense that way, but then I don't
> have to worry that they will be as integral to DCC2 as Send and
> "plain" Chat ;)

I completely agree, partyline should be something seperate. I realize that. 
But I'm not suggesting that we turn chat into partyline, I'm just suggesting 
a few enhancements. I think the CTCP over DCC is a great idea. I see no 
reason why you shouldn't be allowed to see the lag time between you and the 
other chatter, or their idle time, etc. And nicks, I still fail to see how 
nick changing implies that the next step will be partyline. As far as I know, 
it seems most people already agree partyline should be seperate, so I don't 
think that's an issue anymore. The issue now is, should there be some control 
stream over DCC Chat? 

--- codemastr