Feedback for the IDEtalk Jabber integration

Blocking Issues

  • Does not support conversation style chat - see RFC3921 section 4.5

  • Does not support JEP-0045: Multi-User Chat

  • Does not support JEP-0055: Jabber Search. It would be a nice touch if the client automatically performs a JEP-0030: Service Discovery and shows a list of search providers or jump directly to the search dialog if there is only one

  • The client hangs if we try to view the open files and the other side does not use IDEA.

See JEP-0115: Entity Capabilities


Nice to have

  • "User is typing" notification as described in JEP-0085: Chat State Notifications

  • Rich text formatting JEP-0071: XHTML-IM

  • Provide an interface to the open files as JEP-0050: Ad-Hoc Commands

  • A way to subscribe to the list of open files of an user using JEP-0060: Publish-Subscribe



Low Priority

  • JEP-0126: Invisibility

  • JEP-0144: Roster Item Exchange

  • JEP-0112: User Physical Location

5 comments

Hello Dimitar,

First of all, we do not plan to create a full-featured Jabber client.
We want to implement only those Jabber features, which are crucial for
developer communication. And add some functionality, which is specific
for developers (like view open files or send code pointer).


Dimitar Dimitrov wrote:

Blocking Issues


It is possible. But we have some problems with talk.google.com. See

http://www.jetbrains.net/jira/browse/TW-206

  • Does not support conversation style chat - see RFC3921 section 4.5


I'm not sure we really need this functionality. But we plan to
reorganize UI to make conversations more usable (use bottom toolwindow
instead of dialogs and tabs for users).

See http://www.jetbrains.net/jira/browse/TW-147

  • Does not support JEP-0045: Multi-User Chat


Vote for http://www.jetbrains.net/jira/browse/TW-148. So far it is
not of high priority for us. Do you really need this?

  • Does not support JEP-0055: Jabber Search. It would be a nice touch if the client automatically performs a JEP-0030: Service Discovery and shows a list of search providers or jump directly to the search dialog if there is only one


We do not have this in our plans. Currently you can add a user using
JabberID, or use 'Find users' option to find your colleagues who work
with the same *.ipr file.

  • The client hangs if we try to view the open files and the other side does not use IDEA.

See JEP-0115: Entity Capabilities


Looks like a bug. Watch
http://www.jetbrains.net/jira/browse/TW-207


Nice to have

  • "User is typing" notification as described in JEP-0085: Chat State Notifications

  • Rich text formatting JEP-0071: XHTML-IM

  • Provide an interface to the open files as JEP-0050: Ad-Hoc Commands

  • A way to subscribe to the list of open files of an user using JEP-0060: Publish-Subscribe



Low Priority

  • JEP-0126: Invisibility

  • JEP-0144: Roster Item Exchange

  • JEP-0112: User Physical Location


Please file Jira requests for those items you consider
the most 'nice' :) in the TeamWare project:

http://www.jetbrains.net/jira/browse/TW

Thank you for your feedback!

With kind regards,
KIR



--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0

Kirill Maximov (JetBrains) wrote:

First of all, we do not plan to create a full-featured Jabber client.
We want to implement only those Jabber features, which are crucial for
developer communication.


Is it a problem to provide a simple API for plugin writers to enhance it
with features? Something like a Smack connection should be enough.

>> * Does not support conversation style chat - see +RFC3921 section
>> 4.5+


I'm not sure we really need this functionality.


I desperately do - the whole team at my office uses Jabber and whenever
they ping me in IDEA, I have to remember to switch to the other Jabber
client unless I want to flood them with messages. Right now, each
message pops in a new window for non IDEA clients (in IDEA they still
appear as a conversation). That's because the jabber message packet is
missing a 'type' attribute. Shall I add this to TW-147?


>> * Does not support JEP-0045: Multi-User Chat


Vote for http://www.jetbrains.net/jira/browse/TW-148. So far it is not
of high priority for us. Do you really need this?


We have a developer chat room in which everybody hangs. Would be nice to
have it in a toolwindow.

>> * Does not support JEP-0055: Jabber Search. It would be a nice
>> touch if the client automatically performs a +JEP-0030: Service
>> Discovery+ and shows a list of search providers or jump directly to
>> the search dialog if there is only one


We do not have this in our plans. Currently you can add a user using
JabberID, or use 'Find users' option to find your colleagues who work
with the same *.ipr file.


The multicast discovery is not an option for users not on the same
network (and this is a major use-case for Jabber in IDEA). And let's
face it - typing full JIDs sucks.

Please file Jira requests for those items you consider
the most 'nice' :) in the TeamWare project:


Most of these suggestions actually have to do with leveraging the Jabber
protocol and not reinventing the wheel. A major benefit is that you get
basic interoperability with other clients. Also, the Jabber community
has great experience in developing collaboration software, so (with all
respect to the JB developers) there is a big chance that the JEPs would
prove a good foundation for whatever needs IDEA would have. In the end,
it would save you the need to write documentation which is a big win
considering the state of the Open API.

Dimitar

0

Kirill Maximov (JetBrains) wrote:

First of all, we do not plan to create a

full-featured Jabber client.

We want to implement only those Jabber features,

which are crucial for

developer communication.


Is it a problem to provide a simple API for plugin
writers to enhance it
with features? Something like a Smack connection
should be enough.


I see no problem here.


>> * Does not support conversation style chat - see
+RFC3921 section
>> 4.5+


I'm not sure we really need this functionality.


I desperately do - the whole team at my office uses
Jabber and whenever
they ping me in IDEA, I have to remember to switch to
the other Jabber
client unless I want to flood them with messages.
Right now, each
message pops in a new window for non IDEA clients (in
IDEA they still
appear as a conversation). That's because the jabber
message packet is
missing a 'type' attribute. Shall I add this to
TW-147?


Yes, please describe the desired behaviour, that would be real help for us.

http://www.jetbrains.net/jira/browse/TW-148. So far
it is not

of high priority for us. Do you really need this?


We have a developer chat room in which everybody
hangs. Would be nice to
have it in a toolwindow.

>> * Does not support JEP-0055: Jabber Search.
It would be a nice

touch if the client automatically performs a

+JEP-0030: Service
>> Discovery+ and shows a list of search providers
or jump directly to
>> the search dialog if there is only one


We do not have this in our plans. Currently you

can add a user using

JabberID, or use 'Find users' option to find your

colleagues who work

with the same *.ipr file.


The multicast discovery is not an option for users
not on the same
network (and this is a major use-case for Jabber in
IDEA). And let's
face it - typing full JIDs sucks.


That's not quite true. We're considering a way to exchange JabberIDs between project developers. So far it is done via global registry, hosted at JetBrains, where projectID (kept in ipr file as MD5 string) is associated with JabberID of developers who open this project. And user finder consults this registry when you're trying to search users. I agree, that this solution is far from perfect and would be glad to hear your ideas. But simple Jabber search is not the option here, I think.

With kind regards,
KIR

0

Hi Kiril,

I created http://www.jetbrains.net/jira/browse/TW-221 for the OpenAPI
request.

> We're considering a way to exchange JabberIDs between project
> developers. ..... But simple Jabber search is not the option
> here, I think.

Please take the time to read JEP-55
(http://www.jabber.org/jeps/jep-0055.html#intro)

I think it satisfies all your requirements. In a nutshell - when you so
a 'simple Jabber search', the client first sends a request to the server
asking about the available search-fields. The server replies with a list
of fields and then the client sends a search form and server replies
with a list of matching entries. The matching entries's fields can be
different than the search fields. You can see an example here:
http://www.jabber.org/jeps/jep-0055.html#extensibility

Dimitar

0

dimitar wrote:

Hi Kiril,


Please take the time to read JEP-55
(http://www.jabber.org/jeps/jep-0055.html#intro)

I think it satisfies all your requirements. In a nutshell - when you so
a 'simple Jabber search', the client first sends a request to the server
asking about the available search-fields. The server replies with a list
of fields and then the client sends a search form and server replies
with a list of matching entries. The matching entries's fields can be
different than the search fields. You can see an example here:
http://www.jabber.org/jeps/jep-0055.html#extensibility


Thanks, Dimitar, I'll definitely take a look.


Dimitar



--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0

Please sign in to leave a comment.