[JDEV] MIME, was My evil plans for a client.
arh14 at cornell.edu
arh14 at cornell.edu
Mon Aug 9 09:28:12 CDT 1999
On Sun, 8 Aug 1999, Scott Robinson wrote:
> Interleaved response.
> 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
> > > > > 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.
> 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).
More information about the JDev