On Thu Apr 3 13:00:33 2008, Carlo v. Loesch wrote:
So then you have a fundamental decision to take here. Do you
want a swiss army knife like Repeaters or precision tools like
the "smart" series? I stopped being religious on that, I just
want XMPP to move forward as I can't avoid using it myself in
everyday situations.
The trouble is I don't see repeaters as being a swiss army knife. I
see it as being a hammer. Unfortunately, I'm not yet convinced that
all our problems are soluble by hitting them.
That is not an opinion, but the summary gained from the mathematical
model given. No matter which scenario was applied to the model, that
was the result.
No, "is superior" is opinion. "Results in fewer stanzas" is fact.
"May result in an increase in RTT delays" is also a fact. "We have no
idea how bandwidth is affected" is also a fact.
When we wrote the first version we didn't know about the aspect
that allows clients to modify subscription data, and I still think
that's a design mistake in RFC 3921 that should be fixed. But other
people call it a feature.
No, if a client specifies subscription state data in a roster-set,
it's ignored. There's plenty of other, more interesting, problems to
worry about.
| Given that PSYC's webpages suggest that "Only politics can stop
that
| now", I think we may be off to a non-useful conversation, here,
but
| anyway.
Considering how specific and informed the council decided upon the
fate of our efforts, it left a demotivating impression. But maybe
it had indeed nothing to do with politics. Should Multicast make it
into XMPP, then XML is the only thing left really worth criticizing
about XMPP. That's a huge leap forward, even if a vast majority of
people has a hard time understanding there is a problem at all.
Factually it's there. I look forward to removing all the criticism
from websites once the problem has been addressed. Until then, it's
just honesty to leave it as it is.
Actually, no. Stating that any technical decision, if not in your
favour, must be politically motivated is a cheap argument to make,
and is most plainly dishonest, and a pathetic attempt to apply
political pressure onto a technical decision. I cannot possibly
comprehend how you can call that strategy "just honesty", and by
directly attacking my integrity prior to even waiting for the
decision, you've drastically lowered my opinion of you.
| > Not at all. My sendmail is busy until next day to distribute to
a
| > few
| > thousand recipients. Ok, sendmail is stupid, but I wouldn't
want it
| > to
| > try to connect a thousand hosts at the same time. IRC can handle
| > that
| > much better, so does PSYC. How? It just forwards to some thirty
| > hosts
| > which themselves forward to some thirty hosts. Stuff arrives in
near
| > real-time, even with thousands of recipients. That's why
multicast
| > is
| > the only way to go. And persisting recipient lists is
fundamental to
| > have a ghost of a chance of being scalable. I've done this
stuff for
| > a decade now, you can trust I know what I'm talking about.
| Unfortunately, email did this for several years - probably before
| your time - and look what happened.
Hey wait. You can't say email has been multicasting. It has NOT.
There have been relaying servers in UUCP times, but that's history,
and they were hardly ever consciously used for traffic optimization.
NNTP is a protocol that has been sort-of multicasting successfully,
if you want to dig into the past. And yes, NNTP works pretty well -
getting articles distributed worldwide in near real-time. How?
Because of a tree distribution structure!
SMTP allows for multiple recipients for a given message, and I
believe that some servers do indeed collate these such to reduce DATA
commands, by identifying the potential for sharing domains, etc. I
have a vague feeling that zMailer is one such. Most just push per
domain.
Interestingly, we could do the same with XMPP with Repeaters, but I
suspect it's simply too complex to implement realistically, and we'll
end up with one Repeater per domain. Or per domain with more than N
targets, anyway. Where we don't yet know what N might usefully be.
| And please don't say that IRC has done this for several decades,
| unless you want me to have you explain how I can run up my own IRC
| server and talk to anyone else on IRC. Consider, for a moment, why
IRC has been doing multicast for decades, yes. Coming up with the
political issue of IRC not being like XMPP is completely besides the
point. Just because XMPP is better at mostly everything else, it
doesn't mean it doesn't have this one lesson left to learn from IRC.
Original IRC even *was* federated, but the database model didn't
allow for that to stay that way. That's why I started working
on the "next IRC" since the 1990 IRC War. You describe exactly the
point why I started designing PSYC. The difference is, I intended
not to throw away the one major achievement of IRC in the process.
Yeah, IRC was federated back when everyone ran open relays for SMTP.
Its federation didn't scale, and wasn't secure.
| I'm sending you this using SMTP, and not X.400 (my mailserver
*DOES*
| speak both).
No comment.
Yeah, because the obvious comment to make doesn't really promote your
argument, does it?
SMTP (and XMPP) operate with an open flat federation. Basically, this
means that for me to send you an email requires no prearrangement -
you publish your MX records, I connect to the server specified, and
we're talking. For XMPP, it's SRV, but that's simply "Super MX", so
no big deal.
NNTP and PSYC both operate on a closed heirarchical federation (PSYC
is more complex, overlaying multiple fedreation strategies). This
uses prearranged uplinks in order to handle load. It's not the only
method of handling load, but it's a simple one to do. This means that
although I can talk to anyone via these protocols, I need to
initially arrange to connect to the network. As a protocol increases
in value, joining this network increasingly becomes a matter of cost.
(Hence a newsfeed costs actual money. PSYC is, as yet, free).
X.400 operates on a closed flat federation - anyone who I want to
send mail to via X.400 I need to prearrange with in advance, setting
up agreements. There's no spam on X.400, because the spammers would
have to arrange to exchange mail with their targets in advance. It's
also got a few handy properties that make it highly sought after in
some industries. Yet hardly anyone uses it.
There are other open flat protocols, too - although HTTP doesn't do
any meshing, the WWW as a whole is also an open flat federation. I
understand that the WWW is quite popular these days.
You may be excused for thinking that the style, open/closed,
flat/heirarchical, of federation has obvious impacts on
deployability, and that this makes a difference to the utility and
therefore popularity of the protocol.
Doubtless I'm just being political here, but I don't think that's a
baby I want to throw out with the bathwater.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
