[jitsi-dev] Contact Search and import / export


#1

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.

Thank you,

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
Colin.Barr@NFS.StoneRiver.com<mailto:colin.barr@nfs.stoneriver.com>
www.NFS.StoneRiver.com<http://www.NFS.StoneRiver.com>

[cid:image001.jpg@01CE0ACD.4F581870]

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.


#2

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.

I'm not aware that anyone would be working on this. Would certainly be a
useful feature and we'd be looking forward to your contribution!

Please let me know any details on this.

Well I guess you could give it a start by looking at the code that currently
adds a single contact (AddContactDialog and ContactListUtils). The difficult
part would probably be the mapping of the contacts to import to the account,
as it's not necessarily the case that all contacts belong to the same
account.

Thank you,
Colin Barr | System Support Engineer | National Flood Services

Regards,
Ingo


#3

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, colin.barr@nfs.stoneriver.com 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.

Thank you,

*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

Colin.Barr@NFS.StoneRiver.com <mailto:colin.barr@nfs.stoneriver.com>

www.NFS.StoneRiver.com <http://www.NFS.StoneRiver.com>

Low_Res.JPG

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.


#4

Hi Mark,

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
enabled?
    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
additional ones?

  + What is the priority between STUN and Jingle? Both can be enabled?
Which one
    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
everything and
  try and try and try till something suceeds.
   
- Persistence of configurations is unstable. During ICE tests I played
heavily with
  switching options on and of and recognized that, when closing the
configuration window
  and reopening it, it did not have the changes but showed the old
configuration.

  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.

Best regards,
Matt

···

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, colin.barr@nfs.stoneriver.com 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.

Thank you,

*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

Colin.Barr@NFS.StoneRiver.com <mailto:colin.barr@nfs.stoneriver.com>

www.NFS.StoneRiver.com <http://www.NFS.StoneRiver.com>

Low_Res.JPG

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.


#5

Two more things to add:

1. Privacy is another reason why a stable and easy maintainable (export,
import, backup, sync) local contact store is so important. Many
companies policies would not allow data (in this case contacts, phone
numbers etc.) to be stored on external servers (Google Contacts etc.).
In order for Jitsi to be adopted in these environments a local contact
store is a must.

2. If we store contacts in a static form that is only modified through
manual editing it would be good to have an event handler for "contact
modified" as well. This could be used to trigger synchronization scripts
or other notify other applications of a change.

all the best, Mark