[jdev] Re: Local proxy for multiple applications

[aliban]

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.

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.

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
>
>
>  
>