Re: [GnomeMeeting-list] GM 3.00 : PLEASE ALL READ AND CONTRIBUTE

["Bruno Hertz" <brrhtz yahoo de>]

Damien Sandras <dsandras seconix com> writes:

>> I just took a look again at the 1.0.2 phonebook, which I don't use, so I
>> wasn't quite sure what's there already. But I see you already have
>> friends/family/work categories, probably internally maintained as separate
>> boolean attributes. Now, the great thing is that even now an entry can be
>> in several categories. So add 'fav' here, and you have the box a user should
>> check to have an address book entry appear in the contact list window.
>
> The problem is that all of this has heavily changed in 1.2.1 with EDS
> (evolution) integration.
>
> Now, when you edit an user in the address book, you could have a boolean
> indicating if you want it in your favs or not. It should be possible.
> Moreover, each contact can be in one or several categories. That would
> permit to organize them in groups. The only problem I see is that Jabber
> also permits to do this, but on the server-side. So integration will be
> far from easy.
>
> Online/offline status would only be indicated when available.
>
> The roster would be another view of the address book, like you say.


I didn't try that evolution backend yet, but that would have been my
idea anyway, i.e. to get the phonebook load off GM by providing backends
to e.g. evolution, LDAP and/or vCard import/export functionality, to have some
interoperability at least at file level. E.g., if one has nothing else,
one could still write some scripts to sync the contact data between different
applications via vCard (or LDAP ldif, whatever you think is the more widely
accepted interface). That would also allow for standalone operation, where
you don't have online access to some backend.

I just took a look at evolution contacts. Everything is already there,
(multiple) phone numbers, IM contacts, plus categories. You can put
any contact in several categories, including one called 'Favourites'.
The categories are available also in exported vCards. What else do we need?
I.e. I would take the vCard code from evolution, store my native data
in that format, which then is already interchangable with other apps,
and provide online backends only as bonus but not as a requirement to
allow for lean installations. That's all there's needed I guess.

Regarding Jabber, rather than reproducing that functionality I'd
try to provide some interface to e.g. Gaim and other applications
to let themselves dial through GM, i.e. send a message to GM containing
the Jabber URL of the contact to be dialed. GM then looks that URL up in
it's book, gets the contact, picks the (primary?) VoIP number and
dials it. How that interface should look like I'm not sure. At the
very basic level, a 'gnomemeeting -remote' call should be possible,
much like mozilla -remote, to have a running GM instance either dial
a given number, or look up and dial a contact by a given criteria, like
an IM URL.

Of course, you'd then depend on that other apps to provide the 'click dial',
but also for them it's way easier to implement than for you to integrate
Jabber functionality. All they'd need to provide is a configurable command
to be called e.g. through a contact context menu item 'dial'. In other words,
in the Gaim contact context menu, I'd have an item 'dial', and the operation
to performed is specified in the prefs as a command like
'gnomemeeting --remote --im-url %u'
where Gaim would substitute the '%u' with the Jabber URL, which GM
then would look up and dial. That's it, clean and lean. Would provide
an easy interface for other apps, too. Do this, and you can forget
the online status monitoring and the favourite categories and window,
because it's all already there. Plus, dig this, online status monitoring
would then not only include Jabber, but also all IM protos Gaim supports.
All that's needed is having the corresponding URL in the GM (backend)
phonebook, for lookup ...


> Yes, I'll try to do a freeze. I still have something to change, a patch
> to apply to OPAL, and then I'll release 1.3.1 and make it public, with
> the known bugs and problems.


Hail you, Cesar :)


>> Last not least, why do you want to reinvent the IM wheel? Gaim is very good a
>> that. So why not just support the VoIP (e.g. SIP) messaging yourself and for
>> the rest gateway to Gaim? Add Jabber if you like, but I wouldn't go beyond
>> that. Really, while already good, GM is still lacking so many (comfort)
>> features as a softphone, I'd really allocate those precious resources to them.
>> 
>
> That has always been my advice. But I will be honnest, I have one major
> fear, seeing all my users disappearing, and having coded during a few
> years for nothing, just to be beaten by proprietary alternatives like
> Skype, or reverse engineered protocols like the MSN one.
>
> But, probably, I should leave GM as what it is the best at : a
> softphone. Port it to windows to gain more users, but always as a
> softphone.
>
> We'll loose a part of the chatters, but perhaps not all of them.


Sorry to say that, but you're currently in the Open Source/Standards corner,
and when the standards are lacking you'll suffer from that, too. I can tell
you, the asterisk people are thoroughly pissed off as well, by the problems
H323 and SIP impose regarding home user internet telephony, and by the success
of Skype.

That's why,much like the Skype people, they developed their own proto, IAX,
which from what I understand is open but currently more or less specified only
in source code. It doesn't work flawlessly either, especially with regard to NAT,
but it's still a step forward, even more when the encryption they're working on
is available.

But if you hope you'll attract the broad chatter audience with H323 or SIP,
my bet is that you'll be disappointed. The competition is too good already,
especially with respect to ease of use. I currently use SIP, but as you know,
it still needs server support. PC to PC calls or reinvites are practically
impossible with home users, so even media has to go through the server.
Halleluja. And H323 is even more of a hassle.

Sidenote: I didn't examine the inner workings of Skype, but I understand
they're (ab)using user PCs as a replacement for server support, and even route
third party media through them. Now, in my opinion that's a mean and cheap
trick, and stealing bandwidth off users, but apparently they're ready to live
with it ...

I understand your concern, though. But, as I see it, we have to either live
with what's available and suffer from the implications, or, as always, write
our own stuff, i.e. protocol in this case. Either way, my guess is that it'll
basically end up in the classic 'open source lagging behind' situation.

Regards, Bruno.