Re: [GnomeMeeting-list] GM 3.00 : PLEASE ALL READ AND CONTRIBUTE
- From: Damien Sandras <dsandras seconix com>
- To: GnomeMeeting mailing list <gnomemeeting-list gnome org>
- Subject: Re: [GnomeMeeting-list] GM 3.00 : PLEASE ALL READ AND CONTRIBUTE
- Date: Wed, 06 Apr 2005 21:56:21 +0200
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.
[...]
> > 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!
>
> 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
- occasional contacts, they come from the address book
- contacts you will never call anymore, ie you enter the URL directly in
GM
> 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".
[...]
> 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.
[...]
>
> 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?
[...]
> 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.
>
> I'd leave it at the top. Everybody else has it there.
>
ok, let's go for the top, you are right.
> 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 ;)
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
Notice, talking about XTEN, they will also introduce IM with Jabber.
Dunno if it is a trend or the future.
--
_ Damien Sandras
(o- GnomeMeeting: http://www.gnomemeeting.org/
//\ FOSDEM 2005 : http://www.fosdem.org
v_/_ H.323 phone : callto:ils.seconix.com/dsandras seconix com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]