dcdev mailing list

Jesus, there's just so much to talk about.  Again.  Some more.  And then there's all the things that might be new to us.

Is there any short or long-term goals to this list?

Everything I've seen points at slower development, a little talking, not much communication between client and server programmers.  The only exception, is of course Anders/Sarf and his thrice-daily DC++k releases.

Anyhow... so what now, gentlemen (and ladies[?!!?])?

 - Todd / GargoyleMT

As I might've said a few times, I'm very much into your third point. I
know I've expressed myself pretty clumsy, but I've written a doc which I
know fusbar initially thought was a little overkill. It's more or less a
try I'd say, if you all feel it's useless then I'm not the one to keep
on working on it for no use ;)
It was initially just a thought that I just had to write down, and why
don't you have a look at it, if you feel you're interested.

The text about my suggestion of a Supports command can be found at:
http://gempond.com/dcext.txt

Opera

-----Ursprungligt meddelande-----
Från: [email protected] [mailto:[email protected]] För
Fredrik Stenberg
Skickat: den 5 september 2003 08:36
Till: Direct Connect developers
Ämne: Re: [dcdev] Where shall we even start?

3) Documentation of all extended protocol-commands, such as
$Supports, $NetINFO, $BotINFO, $HubINFO, $ZBlock, $UserIP.....
Probably one thread / command.

i-think-i'll-start-with-ctcp-since-i-have-talked-so-much-about-it-ly'ers

/fusbar

On 4 Sep 2003 at 19:51, Todd Pederzani wrote:

Is there any short or long-term goals to this list?

I think this would be a cross-section between the wiki and the main chat, but with better response times and hopefully more elaborate replies ;)
... as long as everyone checks their mail regularly :P

Everything I've seen points at slower development, a little talking,
not much communication between client and server programmers.

the slowness could have a lot to do with ending holidays, and work and/or studies starting again.
the communication between clients and programmers has been.. ..well actually a lot better since more people joined the private hub. although ptaczek and aMutex have been invisible for quite a while there.

Anyhow... so what now, gentlemen (and ladies[?!!?])?

personally, on my todo list are:
- the $UserCommand's
- when I have the time, but mostly the inspiration/courage/will, some sort of Wizard that would set up the nickname, the amount of slots, and the shared directories in DC++
- I think twinks Download-To-PredefinesFolder context menu item is a good thing, and I'd get working on that way before the wizard ;)

- Wallie / Sedulus

--
Walter Doekes <[email protected]>
http://wza.digitalbrains.com/
0xF04B5759 (keyserver.pgp.com)  4E42 CE29 9174 69CA 04BC 8507 44A8 9B73 F04B 5759

Where to start, a good question... to good question to be true. I
have several things on my lists.

1) CTCP, something mimic the behavior of the
client-to-client-protocol used by IRC. See
http://www.irchelp.org/irchelp/rfc/ctcpspec.html for those not
familiar with it. Its through CTCP that IRC support things like
/me, which some clients now supports in DC (oDC at least). The
adding of CTCP to IRC also made DCC possible. But more on this
will described in a separate thread.

2) The login procedure and bandwidth consumed. A couple of days
ago i tested verlihub and my 10Mbit line more or less got maxed
out around 2400 users. I did some stats how much a client received
after login was done. It received 400-420Bytes/S at 2250 users. I
have seen Verliba claiming that (N/20)^2 kbps is a "measure" of
how much bandwidth is used when N users are online. Validate such
formula in it self would be very interesting. Here a lot can be
done, the QuickList approach by Nev and similar. I have also
thought about having user registering if they are passive or
active, and thereby not broadcast passive searches to passive
clients since they do not respond to them anyway. But this will
probably be more than one thread.

3) Documentation of all extended protocol-commands, such as
$Supports, $NetINFO, $BotINFO, $HubINFO, $ZBlock, $UserIP.....
Probably one thread / command.

i-think-i'll-start-with-ctcp-since-i-have-talked-so-much-about-it-ly'ers

/fusbar

On Thu, 4 Sep 2003, Todd Pederzani wrote:

Is there any short or long-term goals to this list?

My basic goal is to get a bunch of pretty hard-core developers together in a
forum where they can discuss without interruption, as opposed to, for
example, the DC++ web forum, or the dcdev hub. And, ofcourse, to
automatically archive what is said, for reference purposes.

Short-term goal:    Everyone gets together in one place
Long-term goal:        We do good stuff for the DC community

;)

/fnord

At 07:51 PM 9/4/2003 -0400, you wrote:

Is there any short or long-term goals to this list?

Anyhow... so what now, gentlemen (and ladies[?!!?])?

My focuses at the moment regarding DC are hashes and more correct hub linking support.

I know that fusbar and sandos have expressed a desire for hashes, and that there's considerable interest among some users who post on the DC++ forums as well.

I hadn't touched the hashing code in a while, until sandos pointed out to me a minor omission that was causing it to behave poorly. Since then, I've fixed that, but it's still not particularly near being ready to be enabled by default.

Hub linking support for the current DC protocol isn't difficult, but rather ugly and nonextensible due to different code required to handle:
(a) $CTM, $RCTM, $To: pulling out the source and target nicks when each has a slightly different format.
(b) $SR: same as (a), but with the additional requirement that the final source nick is stripped from the message itself.
(c) Main chat messages, $MyINFO, etcetera: similar to (a), but handled differently due to their being broadcast messages.
(d) Kick, redirect, and any future messages handled by the hub itself rather than its users.
(e) Login messages: these should probably stay local, so aren't a concern of mine. Their handling must special cased by the hub in any case, so there's no great loss in their having non-standard formats.

fusbar's CTCP proposal strikes me as the nicest way to more easily route DC messages, by standardizing a method by which hubs can determine their sources and destinations. Group (d) would seem to require some sort of null destination group.

-cologic