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 [EMAIL PROTECTED] 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 > > > >
