[JDEV] MIME, was My evil plans for a client.

[arh14 at cornell.edu]

On Sun, 8 Aug 1999, Scott Robinson wrote:

> Interleaved response.
> 
> Scott.
> 
[gratuitious snipping]
> 
> Hmm. Any type of read file transfer done across the Jabber protocol is kinda
> crazy. The problem comes is either you split the message up, then you have
> the problem of no guaranteed messages and how fast are ACKs? Sending it as a
> single file you have the problem of taking the entire connection! Thus,
> CTCP. What I wanted with MIME was a simple method of encoding alternate
> data. If one wanted to have their message as a web-page, they would send a
> message with a text/html MIME part.

This sort of brings me back to my peer-peer question.  File transfer is 
really a high bandwidth, client-side, endpoint-endpoint operation.  There 
really is no reason it needs to go through the server right?  Everybody 
else shouldn't be loaded down when somebody sends their video files to 
each other.  So, is there any reason against allowing (even requiring) 
clients to set up their own peer-peer connections for this type of 
activity?  The only issue I can see is security.  Were there any plans on 
introducing security to Jabber?  If not, what else is preventing 
client-client connections.  If so, can't it then be extended to 
client-client?  I have always seen the messaging "server" as simply a 
router, or DNS server.  Once you know "where" your buddies are, you can 
talk to them directly instead of going through the server.  This 
increases messaging speed and unburdens the server.  In my view, the 
messaging server should really be an event notification server (buddy is 
online, buddy is offline, buddy moved here, etc.).  This doesn't really 
burden the client, since the protocol for client-server is the same as 
for client-client.

> 
> > > > >    If you do this, their damned better be an option so not only do I=20
> > > > > not have to listen to all the shit ppl attach, I don't even have to=20
> > > > > waste time downloading it.
> > > 
> > > Why wouldn't there be?  First of all you would have to accept the
> > > download, and then play the file. 
> > 
> >    With email you can't choose to only download part of a mime 
> > message (or at least I can't in the program I use and have never 
> > heard of anyone doing so), so I had no reason to think it would be 
> > implemented differently, or even feasible to implement differently, 
> > with Jabber.
> > 
> 
> Unfortunately, with the way MIME plain is, you'd be forced to download the
> whole message. However, you wouldn't be forced to look at it. Undocumented
> MIME extensions do exist whereby they send a URL for the part, but I don't
> think we should go there.

Unfortunately you are right...my idea was that we separate MIME parts 
into separate messages which the user could "accept", but this would have 
to be introduced into the protocol...MIME doesn't know anything about this 
and the server would be just as happy stuffing it down the client's throat.

[chop]
> I don't know if this is good news for you or not, but I'm implementing Kruft
> to be basically an embedded web-browser. While you can disable all the
> mailcap/MIME extensions (music, shockwave and all the other extras) if your
> friend has such bad taste to send you a message with a violet background and
> green foreground and his text wRiTtEn LiKe ThIs, there isn't much _anything_
> could do about it. =D

ergh, HTMLitis...is Kruft Win32?  If so the IE component (as much as I shun 
it) would at least be around to embed.  If not, then that would be 
throwing a whole bunch into the client.  What about embedding Gecko 
instead of IE...Gecko is cross platform (well, many-platform).

Aaron