[jdev] Re: Local proxy for multiple applications

Sat Apr 22 08:11:56 CDT 2006

So I made a prototype - withuot any real functionality, without any security, 
with only guesswork using regexps instead of real parsing, but I managed to 
use it to connect using Psi trough it (withou any change in psi code, just by 
setup) and insert other messages into the stream. One day, when it will be 
finished, it would be better if application knew about it, but it will 
tolerate even the "stupid" ones..

So, if is anyone interested in it, it can be found at 
svn://pretel.cz:6400/protoxy. If you want to connect trough it, configure the 
client to connect to localhost:5252 instead of the real server and have a 
look at init.xml. (it needs to change the values, there is a password in the 
ugly looking long line as well). Then start the thing and connect by a 
client. You can open another connection and listen what is incoming and send 
whatever you like to the server.

But it does not do anything like filtering, where a stanza belongs, nor it 
does any security things, like TLS and it uses plain-text password, so do not 
use it with your ususal account.

There is even a small script to insert a message from command line, 
xmpp-message.

It needs Qt4 to work.

If you don't find a bug, then you do not look ;-). But feedback on the idea is 
welcome. This prototype is not ment to work, it mey not even connect to 
server and will not know about it and so on..

Dne sobota 22 duben 2006 14:30 aliban napsal(a):
> interesting :)
>
> well, just as I am curious, do you think this could become part of
> KDE/Gnome one day? Basically the concept is similar to mine with XCD but
> I was not using D-Bus.

Neither was me and will not. ;-)

> Anyway it would be nice if it can be intergrated into a desktop like
> KDE, in example you could browse (disco) with konqueror to xmpp:// -
> konquerer extension could then offer GUI for the xmpp features offered
> by a server/client/component. In this case it could be integrated into
> Kopete as well ...
> In Kontrollzentrum you could also add a config feature.

Well, you can use it with any client (well, will be able to, today, it is 
quite too much dumb and is not too much XMPP compliant, as it is only 
prototype) and use it to insert other comunication without need to do things 
like authentication (well, there will be something, like need to send a 
cookie present in uset environment, to protection) and just send and receive 
what you need. After this, there is no problem integrating it with some 
really simple code into anything (if you just sent a iq and only waited for 
response, you could use usual DOM parsers for that).

> But I am sure you know about this already...
>
> regards
> edrin at jabber.org
>
> Robert McQueen schrieb:
> >Michal Vaner (Vorner) wrote:
> >>Dne pátek 21 duben 2006 19:49 Magnus Henoch napsal(a):
> >>>I haven't looked at it myself but Telepathy might be a place to start:
> >>>http://telepathy.freedesktop.org/wiki/
> >
> >I was about to make a pointer to our project. I'm one of the lead
> >developers on the Telepathy project, and although slightly off-topic for
> >this list, I thought I'd at least answer this seemingly unfaor appraisal
> >of our efforts to date.
> >
> >>Why do simple things in complicated way?
> >
> >Because it's not a simple thing. If you want to create a protocol which
> >can act as proxy for any arbitrary real-time communication protocol you
> >care to name, trying expose less complexity to client authors who don't
> >care about the perculiar features of a given protocol, but not
> >restricting the extensibility of those who do, it's absolutely not a
> >trivial problem.
> >
> >It's similar in form to the problem which XMPP itself aims to solve
> >(making a protocol which is extensible enough to gateway on to other
> >protocols and extend with new features), and you can hardly say the
> >overall result of that is simple, but we've decided to use D-Bus as our
> >basic transport because it has bindings to most popular object systems
> >(glib, qt, python, perl, c#...) that make coding against it pretty easy
> >to get going.
> >
> >If you want something which *is* simple, and discards all of the
> >features of different networks, perhaps Bitlbee would be what you
> >wanted. Everything then becomes just an IRC network where you can only
> >send/receive plain text, but it's just not what the goal of the
> >Telepathy project is.
> >
> >>And why the hell not separate different things as much as possible?
> >
> >We are all in favour of this. Our goal is that protocol code is
> >seperated into backend D-Bus services. Front-end clients which implement
> >particular functionality like managing your contacts, text chats, voice
> >calls, file transfers, etc, interact with different objects provided by
> >these backend services. Different communication types are split out into
> >different objects - we have a Connection object which represents your
> >server connection, from which you can request or be given Channels to
> >perform communications over, of the various types I've mentioned.
> >
> >>Why not use sime pipe or network socket directly?
> >
> >Because then client authors would have to write their own
> >marshalling/demarshalling code. That's about all libdbus does, and a
> >daemon to route messages based on what people have said they do and
> >don't want to receive.
> >
> >>I wanted to provide just a proxy, that would be able to filter the
> >>stanzas out, send them to server and allow some more control using some
> >> other XML. But not move all the ways of comunication to some daemon and
> >> not be able to send custom data that are not supported by the procedure
> >> of RPC for sure?
> >
> >What on earth are you talking about? D-Bus has a completely recursive
> >arbitrary type system. You can send arbitrary structures, arrays, maps,
> >primitive types or any combination of those in any method call, reply,
> >signal or error. So you can send strings, integers, byte arrays, hash
> >tables of strings to arbitrary types, whatever. There is no limitation
> >in the type system I've run into so far, it's pretty elegant.
> >
> >>Why does all the freedesktop projects seem to me as an attempt to make
> >> linux as bad as windows? :-(
> >
> >Ignoring this.
> >
> >>Sorry if I may seem as an extremist here, but this seems to me as a bad
> >> thing. This would disallow the extensibility of the protocol, if used.
> >
> >Nonsense. Telepathy is created from the ground up to allow extra types
> >of communication channel to be added, extra interfaces added to existing
> >channel or connection objects. Our XMPP backend is our main focus at the
> >moment, and it's a very good chance to show how we can expose the power
> >and flexibility of the XMPP protocol within the Telepathy interface,
> >splitting out different tasks like file transfer, audio calls, MUC
> >chats, etc, into the respective channel types within our specification.
> >
> >As I've just posted to our (admittedly rather quiet) mailing list, we
> >think it's going reasonably well at the moment:
> > http://lists.freedesktop.org/archives/telepathy/2006-April/000026.html
> >
> >We're aware of three frontend projects currently on the go, and nobody
> >has come back to us to say the concept is entirely broken and our
> >approach overcomplicated. It's still possible to write something like 10
> >lines of Python and send messages to someone, but by adding more
> >functionality you can take part in a Jabber MUC and manage the room
> >members and settings, place voice calls, manage your roster, etc.
> >
> >We're definitely receptive to feedback about how our approach can be
> >improved, and would love to discuss how we can make Telepathy serve your
> >needs better. It is, after all, intended as a standardisation effort.
> >
> >Regards,
> >Rob

-- 

NAT should extinkt like dinosaurs did.

Michal Vaner (Vorner)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20060422/6c32ff0e/attachment-0002.pgp>