|
List Info
Thread: suppot for serverless IM
|
|
| suppot for serverless IM |

|
2007-10-11 13:52:38 |
Hi the Koffice list told me, that telepathy is integrating
all IM
protocols, would it be possibe to integrate as well this
serverlesss?
Thanks Mike
Instant Messenger.
This one is serverless and uses a QT gui:
http://sourceforge.net/forum/forum.php?forum_id=618174
<<
Hi
I was asking on the K-Mail list to integrate IM into KMail
(like
Thunderbird is doing it) and they told me, that KOffice is
soon
integrating Mail with version 2.0.
I have the suggestion to deliver KOffice 2,0 with an Instant
Messenger.
This one is serverless and uses a QT gui:
http://sourceforge.net/forum/forum.php?forum_id=618174
Can you integrate it for release 2.0 of KOffice
We could call it "K-IM",
Any feedback? thanks Mike
_______________________________________________
Telepathy mailing list
Telepathy lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
a>
|
|
| Re: suppot for serverless IM |
  United Kingdom |
2007-10-12 06:29:22 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 11 Oct 2007 at 20:52:38 +0200, Michael Schmidt
wrote:
> Hi the Koffice list told me, that telepathy is
integrating all IM
> protocols, would it be possibe to integrate as well
this serverlesss?
> Thanks Mike
About the Qt GUI:
The way to integrate this (or any) GUI with Telepathy would
be to make
it use the Telepathy D-Bus API to communicate with
connection managers,
either directly or with the help of Nokia's Mission Control
(NMC) or
basysKom's Decibel. This would enable it to support any
protocol for
which we have a connection manager. Currently that's:
* XMPP/Jabber (Gabble) (interoperates with Google Talk and
others)
* Link-local XMPP, XEP-0174 (Salut) (interoperates with
iChat, Pidgin etc.)
* SIP (telepathy-sofiasip)
* MSN (Butterfly)
* Everything Pidgin supports, including MSN and AOL (Haze,
which uses libpurple)
but anything added by a core or third-party connection
manager can also
be supported.
If KOffice is going to include instant messaging
functionality, I think
it makes a great deal of sense to use Telepathy for it.
I understand there have been some efforts to port Kopete to
be a
Telepathy front-end - you may be able to use code or
libraries from that.
Ideally, Telepathy integration into KDE would follow the
same approach
as we use with Empathy in GNOME:
Empathy mainly consists of a couple of libraries (libempathy
is a non-GUI
convenience library wrapping Telepathy and NMC using GLib;
libempathy-gtk is
a set of GUI widgets using gtk and libempathy).
/usr/bin/empathy itself is
just a trivial wrapper around libempathy-gtk. This makes it
easy to integrate
Empathy widgets into other gtk applications. By replacing
GLib/gtk
references with Qt/KDE ones throughout that description, you
could get some
sort of libkdetelepathy that Kopete, KOffice and any other
KDE app could
use to share IM connections.
- ------------
About the Retroshare network protocol (bear in mind that
today was the
first time I'd heard of this protocol!):
Because of the "network effect" intrinsic to IM
protocols, I don't
believe that inventing or promoting a new protocol is a good
idea. You can't
use a protocol that your friends aren't also on (unless you
can somehow
convince them to use it), and if there's only one
implementation of that
protocol, that's a bad sign.
If you want to promote a protocol or protocols, I'd
recommend XMPP
(Jabber, Google Talk) for conventional server-based
communication across
the Internet, and link-local XMPP (XEP-0174, aka
"Bonjour") for local
networks with no infrastructure or configuration. Both
protocols are
sanely designed and fully extensible.
Elaborating on that a bit:
We already support a serverless link-local protocol,
link-local XMPP
(XEP-0174), which interoperates with iChat and Pidgin (among
others).
It's the same protocol that Apple refer to as Bonjour. Our
implementation
of this protocol, Salut, extends it to feature multicast
chat rooms and
arbitrary collaborative applications over Tubes, is under
active development,
and is a core component on the One Laptop Per Child.
If retroshare is considered useful, integrating it with
Telepathy would
require writing a Connection Manager (a daemon similar to
Salut) that
implements the retroshare protocol instead of XEP-0174. Once
this was
done, any Telepathy user interface (e.g. Empathy) should be
able to
add and use Retroshare accounts.
I'm not really convinced that having more than one
link-local protocol
makes sense, particularly when XEP-0174 is extensible - I
think
we should be encouraging use of XEP-0174 rather than
"fragmenting the
market" - but anyone is welcome to write a Telepathy
connection manager;
the D-Bus spec is available from <http:/
/telepathy.freedesktop.org/spec.html>
and we have Python and C/GLib libraries that can help you
implement a CM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://ww
w.pseudorandom.co.uk/2003/contact/ or pgp.net
iD8DBQFHD1qSWSc8zVUw7HYRAr1PAJ9jRPGKq/J+GSSG4h4cKD5s4+x3SQCg
7uJK
n+P59azgPkiMHjlXx6yyc9U=
=bQ73
-----END PGP SIGNATURE-----
_______________________________________________
Telepathy mailing list
Telepathy lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
a>
|
|
| Re: suppot for serverless IM |

|
2007-10-12 08:21:45 |
Hi Simon
thanks for the advice, telepathy for kde and empathy for
gome and in
general using Bonjour.... mh.. i am not familiar with linux
and cannot
bring it in, just use the idea and support it, Bonjour is
just another
DHT to find a serverless connection. Retroshare offers much
more like
encrypted and safe communication, unlogable and without
servers.
The IM protocol might redesigned later, see the wiki
http://sourceforge.net/forum/forum.p
hp?thread_id=1834409&forum_id=618174
so.. it might be a serverless jabber. But it would be cool,
if someone
of you can tied the new IM to telepathy. As it is encrypted,
in any
case both users have to install something, either encryption
or a
serverless IM, so.. why not right in the beginning using RS?
Getting a
new installation is not the reason not to have this
serverless
protocol, which is indeed messaging from PGP to PGP key.
this is a
cool definition and the DHT makes it serverless. If it is
Kad C or
Bonjour or Opendht.
So... as I am not a coder, thanks for the references, but
just use the
ideas to get yourself on and maybe implement a basic
interface for
this... we really need communication serverless unlogable
and
encrypted. maybe you can help out
thanks Mike
2007/10/12, Simon McVittie <simon.mcvittie collabora.co.uk>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 11 Oct 2007 at 20:52:38 +0200, Michael Schmidt
wrote:
> > Hi the Koffice list told me, that telepathy is
integrating all IM
> > protocols, would it be possibe to integrate as
well this serverlesss?
> > Thanks Mike
>
> About the Qt GUI:
>
> The way to integrate this (or any) GUI with Telepathy
would be to make
> it use the Telepathy D-Bus API to communicate with
connection managers,
> either directly or with the help of Nokia's Mission
Control (NMC) or
> basysKom's Decibel. This would enable it to support any
protocol for
> which we have a connection manager. Currently that's:
>
> * XMPP/Jabber (Gabble) (interoperates with Google Talk
and others)
> * Link-local XMPP, XEP-0174 (Salut) (interoperates with
iChat, Pidgin etc.)
> * SIP (telepathy-sofiasip)
> * MSN (Butterfly)
> * Everything Pidgin supports, including MSN and AOL
(Haze, which uses libpurple)
>
> but anything added by a core or third-party connection
manager can also
> be supported.
>
> If KOffice is going to include instant messaging
functionality, I think
> it makes a great deal of sense to use Telepathy for
it.
>
> I understand there have been some efforts to port
Kopete to be a
> Telepathy front-end - you may be able to use code or
libraries from that.
>
> Ideally, Telepathy integration into KDE would follow
the same approach
> as we use with Empathy in GNOME:
>
> Empathy mainly consists of a couple of libraries
(libempathy is a non-GUI
> convenience library wrapping Telepathy and NMC using
GLib; libempathy-gtk is
> a set of GUI widgets using gtk and libempathy).
/usr/bin/empathy itself is
> just a trivial wrapper around libempathy-gtk. This
makes it easy to integrate
> Empathy widgets into other gtk applications. By
replacing GLib/gtk
> references with Qt/KDE ones throughout that
description, you could get some
> sort of libkdetelepathy that Kopete, KOffice and any
other KDE app could
> use to share IM connections.
>
> - ------------
>
> About the Retroshare network protocol (bear in mind
that today was the
> first time I'd heard of this protocol!):
>
> Because of the "network effect" intrinsic to
IM protocols, I don't
> believe that inventing or promoting a new protocol is a
good idea. You can't
> use a protocol that your friends aren't also on (unless
you can somehow
> convince them to use it), and if there's only one
implementation of that
> protocol, that's a bad sign.
>
> If you want to promote a protocol or protocols, I'd
recommend XMPP
> (Jabber, Google Talk) for conventional server-based
communication across
> the Internet, and link-local XMPP (XEP-0174, aka
"Bonjour") for local
> networks with no infrastructure or configuration. Both
protocols are
> sanely designed and fully extensible.
>
> Elaborating on that a bit:
>
> We already support a serverless link-local protocol,
link-local XMPP
> (XEP-0174), which interoperates with iChat and Pidgin
(among others).
> It's the same protocol that Apple refer to as Bonjour.
Our implementation
> of this protocol, Salut, extends it to feature
multicast chat rooms and
> arbitrary collaborative applications over Tubes, is
under active development,
> and is a core component on the One Laptop Per Child.
>
> If retroshare is considered useful, integrating it with
Telepathy would
> require writing a Connection Manager (a daemon similar
to Salut) that
> implements the retroshare protocol instead of XEP-0174.
Once this was
> done, any Telepathy user interface (e.g. Empathy)
should be able to
> add and use Retroshare accounts.
>
> I'm not really convinced that having more than one
link-local protocol
> makes sense, particularly when XEP-0174 is extensible -
I think
> we should be encouraging use of XEP-0174 rather than
"fragmenting the
> market" - but anyone is welcome to write a
Telepathy connection manager;
> the D-Bus spec is available from <http:/
/telepathy.freedesktop.org/spec.html>
> and we have Python and C/GLib libraries that can help
you implement a CM.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: OpenPGP key: http://ww
w.pseudorandom.co.uk/2003/contact/ or pgp.net
>
>
iD8DBQFHD1qSWSc8zVUw7HYRAr1PAJ9jRPGKq/J+GSSG4h4cKD5s4+x3SQCg
7uJK
> n+P59azgPkiMHjlXx6yyc9U=
> =bQ73
> -----END PGP SIGNATURE-----
> _______________________________________________
> Telepathy mailing list
> Telepathy lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
a>
>
_______________________________________________
Telepathy mailing list
Telepathy lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
a>
|
|
[1-3]
|
|