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

["Bruno Hertz" <brrhtz yahoo de>]

Hello Damien ...


Damien Sandras <dsandras seconix com> writes:

> Hi Bruno,
>
> Le mercredi 06 avril 2005 à 19:25 +0200, Bruno Hertz a écrit :
>> Hi Damien, folks
>> 
>> I included some thoughts which spontaneously came to mind, from a user
>> perspective. They represent just my view, so feel free to ignore them.
>> Hopefully, one or the other remark might still be of use ...
>> 
>
> First of all, all views are interesting, you have spent time reading my
> long mail, and thinking to it, so let me thank you for that! I would
> have felt bad if everybody here had ignored this mail, talking about the
> future of GnomeMeeting.


Thanks very much for considering and responding to my mail. Your remarks
clarified a lot and helped me to better understand the goals and proposals.
Presumably, i misunderstood a few points first time, so lets see ...

>
> [...]
>
>> > Following a few polls, on the mailing list, and formerly on the website,
>> > it appears that GnomeMeeting clearly has two types of users :
>> > 1) users who want to video chat with family and friends. They don't care
>> > about the protocol as long as it is easy, and as long as it works.
>> > 2) corporate users who want to use GnomeMeeting as a softphone with an
>> > IPBX like Asterisk, or Cisco, or anything else.
>> >
>> > There are more users in the first category than in the second,
>> 
>> 
>> This is likely to change with SIP support ( and the increased use of Linux
>> in corporate/public/government environments, of course :) )
>> 
>
> I hope so actually!


I'm pretty confident, actually :) (although, admittedly, softphones will always
have a tough time competing with hard phones in business environments).


>
>
>> 
>> Not sure what you're getting at. Afaik, what you call is always a URL, i.e.
>> in the POTS case either, apart from servers you're registered on, where you
>> may omit the (proto and) domain bit.
>> 
>> So imho at least from the conceptual pov there's no need to distinguish
>> between numbers and URLs. That's by the way how SIP softphones generally
>> work, you can dial an URL, where that particular server is contacted as
>> given in the domain, or simply a number, where it is dialed on the server
>> you're currently registered on. It's the users choice whether he stores
>> complete URLs or just numbers in the phone book.
>> 
>
> Yes, sure, I was making a distinction between the different use cases.
> In all cases, you are calling an URL, in some of the cases (Jabber?) you
> do not need to know that URL to call it. In some other cases, you will
> have it in your address book, but sometimes, like for a phone, it won't
> be the case. So I just meant that there are 3 types of contacts:
> - everyday contacts, you would like to have quick access to them, the
> address book is not the best way to dial their url

Sure. And which come from the address book too, I trust.

> - occasional contacts, they come from the address book

Sure.

> - contacts you will never call anymore, ie you enter the URL directly in
> GM

Right.


A (tabbed) contact list window of course is essential, for quick access
as well as monitoring online status. I seemed to understand though, and
correct me here if I was wrong, that you want to separate address book
and contacts also on data/storage/maintenance level. This would definitely
be the wrong way to go. The contact list should be a view (or select, in
database terminology) on the address book. Like, in pseudo sql,
 select whatever_fields from address_book where fav=true
or something like that.

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 next step of course would be making the contact list selection
variable, e.g. a dropdown list from which I can choose which category
should be shown, like friends, family, etc., much like PDAs and other stuff
works. I.e. by allowing the user to limit a view on the address book by
category, or even the beginning of the name or whatever. I'm not actually
asking for the latter though, just illustrating a point.

I have an increasing feeling that I'm talking about the obvious, so
please apologize if I'm utterly redundant.


>
>> As to LDAP, I presume you mean it isn't realtime with regard to phonebook
>> storage (?) as opposed to read only access. Well, that may be right, I
>> actually don't know how it is generally set up in corporate situations,
>> where I guess you are more likely to find LDAP phone books than on the
>> internet. So yes, Jabber makes more sense for the common internet user,
>> while am LDAP backend still would be nice, but second prio from what you
>> say ...
>> 
>
> Not really second priority. In a sense yes, but more generally, it will
> be kept as it is now, Jabber would be a "plus".


OK, misunderstanding on my part. LDAP is surely not adequate for monitoring
my peers' online status. I was thinking about phone book integration and
storage. Regarding the former, Jabber seems to be the only (open) choice
anyway.


>
> [...]
>
>> Isn't that commonly solved by letting the user store some kind of category(ies)
>> with the contact (cf. e.g. vcard categories)? Like 'family', 'friend', 'biz'
>> or such, so he can e.g. easily limit his view on the phone book to a particular
>> group. Plus, he'd have his favs in the history list either. Or do a category
>> 'top ten', where the users default view is limited to those (which is configurable
>> through prefs, of course). I don't think you want to actually maintain two books.
>> 
>
> You are right about this.
>
> [...]
>
>> That's really an issue where all the standard voip protos seem to be lacking,
>> i.e. checking the peers availability. Jabber would be nice, but at least in
>> my environment few people use it. Nothing better comes to mind, though, so
>> this sure would be a step forward.
>> 
>
> SIP has this, but it is long to implement, and there are no public
> servers, so I would have to provide them myself, which is not possible.
>
> Jabber also has some SIP integration and vice-versa, which is nice.
>


Now that's remarkable. If you could point me to docs/sites regarding Jabber->SIP
integration, I'd be grateful (no need though for that if it's amply available
on the Jabber web site, I'll take a look there soon). But are you sure about
the other direction, since I think SIP is a pure VoIP standard totally unrelated
to Jabber. Maybe you're talking of messaging gateways ... (?) If so, just say
'yes' and I'll find out the rest myself ...


>
>> 
>> Definitely !!!!! It should be a free form field, where you essentially can
>> enter what you want.
>> 
>
> :-)
>
> [...]
>
>> Hm. Here I see group organization mentioned although it wasn't in the phone
>> book vs. contact list discussion above. Apart from that, I myself see no
>> need to group/limit the fav list other than by the aforementioned category.
>> I.e. it wouldn't be fav, it would be book, as said view limited e.g. by
>> category or name. Then, when highlighting an entry, you'd have choices
>> what function to perform on them (buttons, context menu, left/right click
>> or whatever), i.e. call or SIP/Jabber message them. More precisely, I
>> wouldn't mix the operation to perform into the list organization. Nice
>> though to see IAX mentioned here.
>> 
>
> Basically, you would keep the addressbook and not introduce a new type
> of contacts storage?
>
> But in that case, if Jabber support is added, where would you see the
> status of your peers?
>


Well, I'd think the jabber URL of my peer would only be another field in his
phone book entry, just as his phone number is. And the contact list just a
view on the phone book which selects the 'favs', as detailed above. With
separate persistent or even internal storage models, you'd create considerable
maintenance overhead for the user as well as for yourself, as a developer. A
contact object is just a phonebook entry object with fav attribute 'true'
(or 'fav' part of it's category array/vector/whatever). Think model/view/
controller or whatever fits this issue in the OO design world. Contacts
are just a view and are reflected on storage only by an attribute (or the
value of an attribute).


> [...]
>
>> Also, what about some diagnostics somewhere, like control/session package
>> interchange? Don't know, just an idea since users often enough have to
>> debug their stuff especially in nated environments. A topic I see often
>> come up in the * list is one way audio, so some hint whether the client
>> is actually receiving media would be beneficial I guess (e.g. the current
>> statistics I see on v1.0.2 includes only totals, from what I understand).
>> 
>
> In the statusbar you have the current speed, but you are right, more
> hints should be added.


Was just an idea, there is no should. Still, before diving heads first into
IM, there's still a lot one could do for better VoIP, already on the purely
functional and not even yet on debugging/troubleshooting level.

>
>> 
>> I'd leave it at the top. Everybody else has it there.
>> 
>
> ok, let's go for the top, you are right.


I'd wholeheartedly suggest it.


>
>> I myself wouldn't mind having a restricted messaging tabbed window, since
>> I don't expect GM to be that multipurpose. If it does voip, and does it
>> well regarding several protos, including audio quality, latency and stuff,
>> it will be a killer app. Look at what people are complaining about regarding
>> linux softphones on the * list: audio quality and latency. Very few are
>> concerned with messaging, and even more few with video. From own experience,
>> I can tell you that most linux softphones are not really usable because
>> either their internal buffering or audio setup makes them a drag. GM used
>> to be a notable exception, and another is currently coming up, i.e. Xten.
>> It's in the stage of beta testing, I have it here and it goes pretty well.
>> To the point that I'm myself considering using it instead of GM until SIP
>> support is available.
>> 
>> 
>
> As long as you come back to GM, but you should really try CVS with SIP,
> it works well, especially with Asterisk ;)


I'll take this then as the announcement you promised me here
http://mail.gnome.org/archives/gnomemeeting-list/2005-February/msg00018.html
when I last tried to 'build the beast' in February :) OK, I'll try
the next time I get around to it. If you have an intermediate alpha you know
works reasonably well, you could store it away somewhere also, btw., since
quite a few other people have been asking about GM SIP either. And you know how
things go with CVS, fine today, broken tomorrow ...


>
> But there are many alternatives, I guess most users do not want a
> softphone, they want to do simple audio chat, like Skype, like MSN
> Messenger, that is why I wanted to create an hybrid.
>
> But I see now that I have some users like you who prefer the softphone
> approach.
>
> So I will rephrase my question in another way.
>
> Should GM become :
> - a softphone, what it is now
> or
> - an hybrid: mainly a softphone with IM capabilities
> or
> - an hybrid: mainly an IM support voip
>


That's what I already said, there basically are no viable softphone
alternatives. You obviously aren't aware of how unique your software actually
is on Linux. Just recently I helped some newbie to set up asterisk with
H323 support because he *insisted* to use GM, being the only phone he
could live with. Now, what does that mean to you? Again, among the
advantages GM has over other Linux softphones are, besides video, the
good audio quality/latency balance, robustness (I never got it to hang
or crash) and the clean interface (!)

On the other hand, if you want to go the chat way and compete with Skype,
just go ahead, but I'm pretty sure you've lost already. H323 and SIP (and
hopefully IAX at some point) are the real deal, full fledged telephony
protocols for serious and powerful applications, private and business,
but definitely difficult to set up for internet use without proper server
support. Just consider the NAT issues, and what troubles even experienced
end users have with that. Video is the only advantage you currently have over
Skype, and even if you add IM to that (how popular is phonegaim btw, not at
all I'd say), as soon as Skype chooses to support video too your dear chatters
will go and drop GM like a hot potatoe.

On the other hand, if you'd choose to polish GM, add multiple lines, call
holding, transfer, conferencing and all that comfort stuff, plus, finally,
encryption, I'm sure if softphones will ever play a major role in serious
business, GM will be a notable player.

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.


>
> Notice, talking about XTEN, they will also introduce IM with Jabber.
> Dunno if it is a trend or the future.


I guess not. Rather, the trend will be a sensible VoIP protocol yet to be
written, which is NAT and firewall friendly, offers encryption, messaging
integration and video support. Unfortunately, the geniuses who wrote H323 and
SIP apparently weren't fully aware of all of these points. Skype is, but they
don't write anything, they just place their products to make money (which is OK,
by the way). So the others go along patchworking, to get at least parts of the
cake. What a mess, really ....

Anyway, apos for the rant, but I'd really be sorry if you went with the chatters
who I feel take whatever comes along, and are going with Skype already anyway.
My 2 cents (Euro wise :) )

Regards, Bruno.