I definitely support an overhaul of contact handling!
And you certainly can be uneasy. We have quite often instabilities
in the contact list and do lose contacts some times.
Lets say it like this: I am convinced of Jitsi but think
that it is far away from being enterprise ready in the sence
of resiliance, stability and usability. Not to complain, we
still use Jitsi but we are very good natured to issues arising.
In thi sense I have already called a vote for a consolidation
period (2-3 months or so?) which focuses on bug fixing, resiliance
(like contact maintenance, connection stability (retrials)),
start up performance, and ease of use and completely stop
any new features in this period (or only cosmetic changes).
I think this would bring the project a big step forward.
Issues we discovered so far:
- Slow startup.
- Instable contact handling (sometimes contacts are lost).
- Very sensible to entered strings. Display name with "< or >" in sip
contacts does not work.
- Stale chat windows when packages / connections are lost in between.
Have to be closed and reopened.
- Very susceptible against temporary packet/connection loss. Retrial
takes very long (and leads to the stale chat windows).
- Disconnecting of calls takes quite long. This leads to problems
such that a quick switch betwenn calls is not possible. When disconnecting
and quickly calling another number it hangs in "initiating call". One has
to close this again and retry to get it to work.
- For second calls (coming in when being in a call) sometimes the accept
dialog is not shown. This happens very rarely also for first calls.
- Ease of use
Overloaded and not clear designed configuration pages. Example is
"ICE configuration" in XMPP contact. All are option boxes and by default
everything is enabled. So what is the functionality? What is the clear
configuration to use or not to use? Questions like
+ Must "Use ICE" be enabled such that all functions on the page are
This is because configuration page has Title "ICE configuration".
+ Must "Use ICE" be enabled when enabling "use Google's Jingle/ICE..."?
+ "Auto discover STUN/TURN servers" versus "Additional STUN servers".
What is the priority there? First auto discover or first the
+ What is the priority between STUN and Jingle? Both can be enabled?
will then be used?
+ Is "Use Jingle Nodes" needed when having "Additional Jingle Nodes"?
I think becaus of all this people went the way to enable just
try and try and try till something suceeds.
- Persistence of configurations is unstable. During ICE tests I played
switching options on and of and recognized that, when closing the
and reopening it, it did not have the changes but showed the old
In this sense, where is a "Save" button? A very bad GUI interaction
design, if you ask me.
No one followed the basic GUI design principles
- No interdependencies.
- No implicit hidden functions (like the whatever "is automatically
saved"... is it or not?)
- Clear cut between different responsibilities.
- Validation of all data entered in fields (syntax validation).
- Make dependencies explicit on a form -> no implicit dependencies on
fields/buttons/option boxes, etc.
- No overloaded configuration windows.
Sorry guys for hammering. But this are our experiences with it and I
would like to see Jitsi go int
being enterprise capable.
Aside from bug fixing there are also some little feature requests ...
but enough for now.
Please please, could the responsible persons arrange for a consolidation
period where every committer/
supporter would contribute in this phase to achieve the goals. Jitsi has
so many functionalities
(which I really like) that I fear that things will get worse when
continuing to focus
on new functionality. By the way, we call this featureritis.
Am 15.02.2013 13:21, schrieb M Dammer:
The contacts in jitsi are already stored in an XML file
(contactlist.xml), but the problem is that this file seems to get
touched and modified by jitsi all the time. This makes it impossible
to properly import contacts, backup/restore contacts or synchronise
this file with another jitsi installation on another computer. And I
am a bit uneasy about this file getting corrupted for whatever reason
and maybe hundreds of contacts getting lost.
My proposal would be to separate out the dynamic and the static storage:
- one file, lets call it buddycache.xml that holds all the dynamically
updated buddies and their status etc.
- the real contactlist.xml file is now a static contact store. This
file holds all contacts that have been added manually to jitsi
(including sip addresses etc.). Jitsi only modifies the file when a
contact is added or modified manually. The file format is as simple
XML as it can get - meaning here that there are no data stored in this
file that makes it unique to this particular jitsi installation thus
allowing copying, editing, modifying, backing up and restoring and
doing all kinds of useful things with this contactlist.
This would create much more flexibility with the contact store - in
particular on Linux machines where there still is no standardized
system address book.
What do the other developers think about this suggestion ? Could this
be implemented soon ?
all the best, Mark
On 14/02/13 21:06, firstname.lastname@example.org wrote:
Our company runs an internal openfire server for chat. We had used
spark in the past, but with it lacking updates with java 7, we are
looking to move to another source.
The only real problem I see we would have with using jisti is the
lack of import contacts from an xml file, exported by another user.
Along with the ability to search our server for contacts, instead of
having to know their exact name.
I would be interested in working on development of these abilities,
but am not sure if such a task is underway at the moment.
Please let me know any details on this.
*Colin Barr* | System Support Engineer| *National Flood Services*
StoneRiver | 555 Corporate Drive | Kalispell, MT | 59901
888.888.2169 x4163| Mountain Time
406.755.4403 | Facsimile
Confidentiality Notice: This E-mail, including any attachments, is
for the sole use of intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and
destroy all copies of the original message
NOTICE: The preceding email message may be confidential or protected
by privilege. It is not intended for transmission to, or receipt by,
any unauthorized person. If you have received this message in error,
please (i) do not read it, (ii) reply to the sender that you received
the message in error, and (iii) erase or destroy the message.