Thanks Niklas Actually, we're going to look at a tighter integration because we really want our socks5 handling to live [inproc] with vysper - where vysper is embedded in our webapp. In addition, if there's a way to tie directly into the Socks5 proxy - without even using a TCP socket, I'm going to take a look at that.
So, my plan is to do the following: 1) derive our own class from the DefaultDiscoAwareModule + implement the Component interface, too - so our component plugs into Vysper, and is externally addressable (for file transfer) 2) implement our own IQ handling - as opposed to using SMACK 3) see if there is a way to hook directly into the Socks5 proxy via Mina [or some other way] - to avoid even creating a TCP socket, but instead going direct since we know we're in the same JVM/process If you wouldn't mind, can you let me know if you see any obvious problems with our approach? If we can't do #3, we'll manage it via an inproc socket connection, but I figured it was worth investigating and should simplify the communication between our custom component and the socks5 proxy logic - if it's possible. Thanks again, Bob -----Original Message----- From: Niklas Gustavsson [mailto:[email protected]] Sent: Friday, December 09, 2011 2:50 AM To: [email protected] Subject: Re: inproc socks5 proxy client On Thu, Dec 8, 2011 at 11:42 PM, Bob DeRemer <[email protected]> wrote: > Actually, I may have seen that class, but wasn't sure really where to start. > When you say "component" do mean this in the general sense, or an actual XMPP > component? Would this make sense to be a module? I meant that as the more general component, running within your greater application, or inside Vysper if that makes any sense. If it were to run within Vysper that should be if there's any need for tighter communication with Vysper, which I'm not sure there is here. /niklas
