Re: [JDEV] Large Jabber Messages

[Waster_ <waster@iname.com>]

I was reading the old JDEV messages and found that message. I think using
HTTP will only give us file-transfers. Maybe we can use a forwarding server?

- Client A will connect to forwarder and send the line "CREATE"
- Forwarder will send Client A a line containing a key: "ggvsHfajsgs"
- Client A will send the address of the forwarder and the key to Client B.
- Client B will connect to forwarder, and send the key in a line.
- Forwarder will send Client A an empty line meaning that Client B connected.
- When Client A gets the empty line (after key),  it will understand that Client B
  connected.
- Now everything a client sends will be forwarded to the other one without modifiying.
- When one of the clients disconnect, the forwarder will simply disconnect the other
  client.

- Note that everything that will happen between client/forwarder (not client/forwarder/2.client)
  is a line.

Just a thought.
            Kerem 'Waster_' HADIMLI

Jeremie Miller wrote:

> Well, the one-socket connection scheme isn't really designed to be the
> carrier for lots of data, either in big messages or in a large constant
> stream of small ones.  It's really just supposed to be the "control"
> channel where all of the instructions/messages are passed.  The bulk of
> the "data" traffic for large things such as files, voice samples, other
> multimedia, etc, really needs to go elsewhere.
>
> I'm still working on the spec for this stuff that I started a few weeks
> ago in a post to jdev, to handle bulk data via HTTP/1.1.  Simply, a system
> where:
>
> --Client serves data on local high port and sends HTTP URN to other client
> --Client connects to special HTTP server and PUTs file then sends that URN
> --Client sends data to "streaming" HTTP server that others recieve from
>         (a-la shoutcast!)
> --Cleint tells HTTP proxy about self and sends proxy URN to recipient
>         (hides IP address)
>
> Basically, Jabber would use/rely on any sort of HTTP system, and this data
> would be sent to client as URN's that a client can do a simple GET.  It's
> an existing and proven way to do this stuff, and there's lots of
> experience and code out there.
>
> I just need to sit down and detail out how it would specifically interact
> with Jabber and at what level, but I'm working on 0.6 at the moment so
> well see after that's released :)
>
> Jer