[Standards] [LONG] Jeez, Sorry (was: All your problems, solved ; ))

Jonathan Chayce Dickinson chayce.za at gmail.com
Mon Aug 27 21:56:39 UTC 2007


I'm sorry. Didn't mean any harm. I'm not too hot on bandwidth here, so I 
didn't come across MTOM.

I wasn't wasting your time, quote: "Didn't want to push this forward 
until I got some feedback". I don't like wasting people's time, hell, I 
love helping people out and solving problems: don't reply to this and 
you will never hear of it again; all it takes is "nope, not a good 
idea," not something as violent as "fanciful" (ouch!).

Read the spec and you will see that it has a lot to do with XMPP: Namely 
(quoted from my draft):

1. DIME will rectify the absence of true In-Band Bytestreams, as it 
defines methods to send multiple payloads in a atomical message. Each 
payload in the message can reference other payloads in the message.

XMPP needs, in my opinion, a way to negotiate real in-band bytestreams. 
Base64 seems like a cop-out to me, it really does.

2. Furthermore compression methods used by servers (which tend to be 
fast instead of -small-effective) will, at best, return the data to near 
it's original length. If the data is presented to these algorithms in 
its original state they may be able to compress it even further.

Not everyone has a T3 connection at home, some of us live in South 
Africa, and well, bandwidth here is rather expensive: and so is a static 
IP (yes, we differentiate between them here, we /actually/ have 
non-static ones too). When you have to weigh up the value of 1MB, you 
will know.

3. Ultimately this protocol will smooth out the issues plaguing Jabber 
regarding file sharing.

This was a hot topic on JDev not too long ago! Demand, supply. If the 
developers are demanding it, I ASSURE you, the users will be fast 
following (faster than any cheetah metaphores ;)

4. Almost all the existing XEPs should be able to derive some further 
benefit from this extension (especially Jingle and SI).

That is a bit fanciful and ambitious, I admit. Add XHTML to that list, 
and well there you go, not even nearly all, but 3, which is a start.

(Just coming in on that regard, SOAP has nothing to do with XMPP, but 
neither did SASL (at the start), or XHTML... And there is SOAP over XMPP 
now)

And, well, *both* are XML and *both* suffer from the fact that you can't 
package binary data reliably and efficiently in an XML document. MTOM 
wouldn't exist if it wasn't a real problem. It would have ended with DIME.

A lot of protocols do it, hell, even your cellphone does something 
similar (which is why you can call someone and surf over GPRS/3G/HSDPA 
at the same time).

In regard to Dave's email, about the negative compression etc. very 
true, didn't think of that. Nice, constructive criticism. Dave: the very 
reason I thought of it was because a P2P connection isn't always 
possible, as in my case (I don't need it, but the awareness is there). I 
was hoping to use the server to host the Peer-To-Host-To-Peer connection 
instead of some 3rd party website/ftp server.

I saw a gap, jumped, it seemed like a good idea, but it obviously 
wasn't. Sorry about putting your name on it Peter: it was in the 
template, I thought it belonged there. I'm sorry I put this out there, I 
could have just as easily made the whole thing a undocumented protocol 
on the project I am working on, which actually, ironically, REALLY needs 
it: and probably will land up doing now anyway.

On that note, it was nice contributing to the Jabber scene, but I should 
really take my leave. I just thought the OSS/OSI community was made up 
of people with broader minds, a.k.a Dave. Peter just read the two emails 
and look at the elegant way in which Dave substantiated his response, 
instead of "your ideas suck".

There are some things schools can not teach you about English, I read 
this email about 5 times before I sent it, asking myself, "how may I 
hurt the other person?" Politicians go to university for a reason, so 
that they don't screw up international relations by saying something, 
well, 'unpolitical'. Peter, I really did think more of you.

Note the insertions:

Peter Saint-Andre wrote:
> Jonathan Chayce Dickinson wrote:
>> Hey People,
>>
>> I was perusing over a couple of MSDN articles, when I came across DIME
>> (Direct Internet Message Encapsulation). Jeez, I thought, that would fix
>> all the file issues in Jabber (like SI). So I wrote a draft, any takers?
>> What do you all think? Didn't want to push this forward until I got some
>> feedback.
> 
> Please don't waste our time with fanciful notions like this.

Really, ouch!

> 
> I say it is a fanciful notion because:
> 
> 1. DIME was some Microsoft technology.
> 
> 2. Which they submitted to the IETF in 2001 and never updated.

So what, they abandoned it, it remains viable. The gun was a huge advent 
in terms of war, it turned knives/swords obsolete, yet you still find 
them on guns in the form of a bayonet.

> 
> 3. Which they then abandoned in favor of "SOAP Message Transmission
> Optimization Mechanism" (MTOM).

Why do we have MTOM now? Probably DIME. Note: Optimization.

> 
> 4. Which in turn basically has nothing to do with XMPP or anything we
> would work on here.

Which, in turn, basically has EVERYTHING to do with eXtensible (a.k.a 
XML, a.k.a SOAP, a.k.a Messaging, a.k.a *The Internet*) Messaging and 
Presence Protocol.

> 
> And I don't know why my name is on the protoXEP you wrote up, because I
> had nothing to do with this.

Once again, sorry, maybe you should remove it from the template and put 
Romeo there instead as an example.

> 
> Peter
> 

How frustrating. You try to help out: really, I wrote a whole freaken XEP.

Jonathan Chayce Dickinson

-- 
jonathan chayce dickinson
ruby/c# developer

email:  chayce.za at gmail.com
jabber: moitoi at inflecto.org

<some profound piece of wisdom>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6974 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070827/6fbd93a1/attachment.bin>


More information about the Standards mailing list