Is there any utility class or method to help find out if Jitsi is
already present on a system?
No. The best you could get are default installation paths, but those are OS
(and on Linux distribution) dependent. Also, you can launch Jitsi as often
as you want (preferably with different configuration directories, or it'll
end up with a mess).
What are you trying to achieve?
Ingo
···
On 2014-07-31 20:40, Daniel Pocock wrote:
Is there any utility class or method to help find out if Jitsi is
already present on a system?
There are many other Java applications out there, both standalone and
web start, that could potentially offer a click-to-chat or click-to-call
button for users of the application to chat to each other or a help desk.
java.awt.Desktop provides a very simple way to launch a sip: or xmpp: URI
If no URI handler is defined, it throws IOException
In this case, it would be good to try and provide some logic to
a) find an existing copy of Jitsi and launch it, possibly giving it a
hint to associate itself with the URI scheme
or
b) start a download/install of Jitsi, either using JNLP or some other means
Another related requirement is account settings: it is no good finding
or installing Jitsi this way if it only has an XMPP account configured
and the request was to call a SIP address. Maybe some URI parameter
could be used to give Jitsi a hint about how to make an account if none
exists, e.g.
/usr/bin/jitsi sip:daniel@pocock.pro?x-jitsi-account=(coded filename)
The reason I suggest making this a URI parameter is that a successful
call to java.awt.Desktop.browse() does not provide any way to send other
command line arguments to Jitsi.
···
On 31/07/14 16:46, Ingo Bauersachs wrote:
On 2014-07-31 20:40, Daniel Pocock wrote:
Is there any utility class or method to help find out if Jitsi is
already present on a system?No. The best you could get are default installation paths, but those are OS
(and on Linux distribution) dependent. Also, you can launch Jitsi as often
as you want (preferably with different configuration directories, or it'll
end up with a mess).What are you trying to achieve?
What are you trying to achieve?
There are many other Java applications out there, both standalone and
web start, that could potentially offer a click-to-chat or click-to-call
button for users of the application to chat to each other or a help desk.java.awt.Desktop provides a very simple way to launch a sip: or xmpp: URI
That could be any application, not just Jitsi.
If no URI handler is defined, it throws IOException
In this case, it would be good to try and provide some logic to
a) find an existing copy of Jitsi and launch it, possibly giving it a
hint to associate itself with the URI schemeor
b) start a download/install of Jitsi, either using JNLP or some other
means
Are you thinking of doing this from within your 'other' application?
We already pass arguments to an already running instance, so this shouldn't
be a problem. However finding a non-running one... I can't think of a way
other than searching the system for known paths. On Windows the registry
might help to check for the path of the xmpp: and sip: handlers.
Another related requirement is account settings: it is no good finding
or installing Jitsi this way if it only has an XMPP account configured
and the request was to call a SIP address. Maybe some URI parameter
could be used to give Jitsi a hint about how to make an account if none
exists, e.g./usr/bin/jitsi sip:daniel@pocock.pro?x-jitsi-account=(coded filename)
The reason I suggest making this a URI parameter is that a successful
call to java.awt.Desktop.browse() does not provide any way to send other
command line arguments to Jitsi.
What would (coded filename) contain? Account properties? What about the
password encryption? Something like this would certainly be possible to
catch somewhere in the ArgHandler.
Ingo
···
On 2014-08-01 02:06, Daniel Pocock wrote:
On 31/07/14 16:46, Ingo Bauersachs wrote:
What are you trying to achieve?
There are many other Java applications out there, both standalone and
web start, that could potentially offer a click-to-chat or click-to-call
button for users of the application to chat to each other or a help desk.java.awt.Desktop provides a very simple way to launch a sip: or xmpp: URI
That could be any application, not just Jitsi.
That is quite OK - it doesn't have to be Jitsi, but if there is no such
application on the system, then starting a Jitsi install (maybe calling
Desktop.browse with a JNLP URL) may be the next step.
If no URI handler is defined, it throws IOException
In this case, it would be good to try and provide some logic to
a) find an existing copy of Jitsi and launch it, possibly giving it a
hint to associate itself with the URI schemeor
b) start a download/install of Jitsi, either using JNLP or some other
means
Are you thinking of doing this from within your 'other' application?
Yes
We already pass arguments to an already running instance, so this shouldn't
be a problem. However finding a non-running one... I can't think of a way
other than searching the system for known paths. On Windows the registry
might help to check for the path of the xmpp: and sip: handlers.
I agree there is no convenient and precise way to do this. Maybe it is
possible to make a class that does this successfully for 80% of users
though.
Another related requirement is account settings: it is no good finding
or installing Jitsi this way if it only has an XMPP account configured
and the request was to call a SIP address. Maybe some URI parameter
could be used to give Jitsi a hint about how to make an account if none
exists, e.g./usr/bin/jitsi sip:daniel@pocock.pro?x-jitsi-account=(coded filename)
The reason I suggest making this a URI parameter is that a successful
call to java.awt.Desktop.browse() does not provide any way to send other
command line arguments to Jitsi.What would (coded filename) contain? Account properties? What about the
password encryption? Something like this would certainly be possible to
catch somewhere in the ArgHandler.
Yes, it could be used to pass account properties
Or maybe there can just be a URI parameter that hints to Jitsi that it
should create an anonymous SIP account without registration
···
On 01/08/14 11:37, Ingo Bauersachs wrote:
On 2014-08-01 02:06, Daniel Pocock wrote:
On 31/07/14 16:46, Ingo Bauersachs wrote:
What are you trying to achieve?
There are many other Java applications out there, both standalone and
web start, that could potentially offer a click-to-chat or click-to-call
button for users of the application to chat to each other or a help
desk.
java.awt.Desktop provides a very simple way to launch a sip: or xmpp:
URI
That could be any application, not just Jitsi.
That is quite OK - it doesn't have to be Jitsi, but if there is no such
application on the system, then starting a Jitsi install (maybe calling
Desktop.browse with a JNLP URL) may be the next step.
Well, I guess this is outside of our scope, so feel free to do that 
If no URI handler is defined, it throws IOException
In this case, it would be good to try and provide some logic to
a) find an existing copy of Jitsi and launch it, possibly giving it a
hint to associate itself with the URI schemeor
b) start a download/install of Jitsi, either using JNLP or some other
means
Are you thinking of doing this from within your 'other' application?
Yes
We already pass arguments to an already running instance, so this
shouldn't
be a problem. However finding a non-running one... I can't think of a way
other than searching the system for known paths. On Windows the registry
might help to check for the path of the xmpp: and sip: handlers.I agree there is no convenient and precise way to do this. Maybe it is
possible to make a class that does this successfully for 80% of users
though.
As the search would have to be done from outside of Jitsi, can we do
something else than to provide you with a list of known installation paths?
On Windows its %ProgramFiles%\Jitsi\jitsi.exe or
%ProgramFiles(x86)%\Jitsi\jitsi.exe (or even both). I don't know Mac, and
you're the Linux guru
Another related requirement is account settings: it is no good finding
or installing Jitsi this way if it only has an XMPP account configured
and the request was to call a SIP address. Maybe some URI parameter
could be used to give Jitsi a hint about how to make an account if none
exists, e.g./usr/bin/jitsi sip:daniel@pocock.pro?x-jitsi-account=(coded filename)
The reason I suggest making this a URI parameter is that a successful
call to java.awt.Desktop.browse() does not provide any way to send other
command line arguments to Jitsi.What would (coded filename) contain? Account properties? What about the
password encryption? Something like this would certainly be possible to
catch somewhere in the ArgHandler.Yes, it could be used to pass account properties
I guess we'd be open to have some way to dynamically add an account, e.g. by
specifying the protocol provider factory and a set of properties for the
account.
However, I guess the user would need to informed about it and give his
consent before actually installing the account.
Or maybe there can just be a URI parameter that hints to Jitsi that it
should create an anonymous SIP account without registration
That doesn't sound to useful to me?
···
On 2014-08-01 17:55, Daniel Pocock wrote:
On 01/08/14 11:37, Ingo Bauersachs wrote:
On 2014-08-01 02:06, Daniel Pocock wrote:
On 31/07/14 16:46, Ingo Bauersachs wrote:
What are you trying to achieve?
There are many other Java applications out there, both standalone and
web start, that could potentially offer a click-to-chat or click-to-call
button for users of the application to chat to each other or a helpdesk.
java.awt.Desktop provides a very simple way to launch a sip: or xmpp:
URI
That could be any application, not just Jitsi.
That is quite OK - it doesn't have to be Jitsi, but if there is no such
application on the system, then starting a Jitsi install (maybe calling
Desktop.browse with a JNLP URL) may be the next step.Well, I guess this is outside of our scope, so feel free to do that
That is actually quite trivial:
Desktop dt = Desktop.getInstance();
URI contact = new URI("sip", "ingo@jitsi.org", null);
try {
dt.browse(contact);
} catch (IOException) {
// Maybe show a popup first to ask user if they want to install Jitsi
dt.browse("https://jitsi.org/jitsi.jnlp");
// Maybe show a popup here,
// "Jitsi is installing, when finished, please click Retry to attempt
the call again"
}
If no URI handler is defined, it throws IOException
In this case, it would be good to try and provide some logic to
a) find an existing copy of Jitsi and launch it, possibly giving it a
hint to associate itself with the URI schemeor
b) start a download/install of Jitsi, either using JNLP or some other
means
Are you thinking of doing this from within your 'other' application?
Yes
We already pass arguments to an already running instance, so this
shouldn't
be a problem. However finding a non-running one... I can't think of a way
other than searching the system for known paths. On Windows the registry
might help to check for the path of the xmpp: and sip: handlers.I agree there is no convenient and precise way to do this. Maybe it is
possible to make a class that does this successfully for 80% of users
though.As the search would have to be done from outside of Jitsi, can we do
something else than to provide you with a list of known installation paths?
Yes, I'm not asking you to provide a magic solution
It would be nice to create a JAR with this functionality and keep it in
the Jitsi area on Github and also publish it for Maven users.
I don't mind making a first version of it if somebody can create a
Github repo and give me access, e.g. https://github.com/jitsi/uri-launcher ?
Then other people can contribute platform-specific things as pull requests.
On Windows its %ProgramFiles%\Jitsi\jitsi.exe or
%ProgramFiles(x86)%\Jitsi\jitsi.exe (or even both). I don't know Mac, and
you're the Linux guruAnother related requirement is account settings: it is no good finding
or installing Jitsi this way if it only has an XMPP account configured
and the request was to call a SIP address. Maybe some URI parameter
could be used to give Jitsi a hint about how to make an account if none
exists, e.g./usr/bin/jitsi sip:daniel@pocock.pro?x-jitsi-account=(coded filename)
The reason I suggest making this a URI parameter is that a successful
call to java.awt.Desktop.browse() does not provide any way to send other
command line arguments to Jitsi.What would (coded filename) contain? Account properties? What about the
password encryption? Something like this would certainly be possible to
catch somewhere in the ArgHandler.Yes, it could be used to pass account properties
I guess we'd be open to have some way to dynamically add an account, e.g. by
specifying the protocol provider factory and a set of properties for the
account.
However, I guess the user would need to informed about it and give his
consent before actually installing the account.
That type of popup seems quite OK
It is very constrained by the fact that the URI handler (invoked using
java.awt.Desktop.browse()) can only receive one argument, the URI. That
is why I suggest adding something as a URI parameter rather than a
regular command line parameter.
Or maybe there can just be a URI parameter that hints to Jitsi that it
should create an anonymous SIP account without registrationThat doesn't sound to useful to me?
SIP does allow anonymous calls,
http://tools.ietf.org/html/rfc3323.html#section-4.1.1.3
Some applications will be willing to accept anonymous calls and may use
some custom URI parameter to authenticate the user, much like web sites
use cookies instead of HTTP DIGEST
One issue I notice trying this with Jitsi is that it always seems to try
UDP for accounts that don't register, even if the destination has a
NAPTR for TLS.
···
On 01/08/14 12:12, Ingo Bauersachs wrote:
On 2014-08-01 17:55, Daniel Pocock wrote:
On 01/08/14 11:37, Ingo Bauersachs wrote:
On 2014-08-01 02:06, Daniel Pocock wrote:
On 31/07/14 16:46, Ingo Bauersachs wrote:
From: <anonymous@anonymous.invalid>
We already pass arguments to an already running instance, so this
shouldn't be a problem. However finding a non-running one... I can't
think of a way other than searching the system for known paths. On
Windows the registry might help to check for the path of the xmpp: and
sip: handlers.I agree there is no convenient and precise way to do this. Maybe it is
possible to make a class that does this successfully for 80% of users
though.As the search would have to be done from outside of Jitsi, can we do
something else than to provide you with a list of known installation
paths?
Yes, I'm not asking you to provide a magic solution
It would be nice to create a JAR with this functionality and keep it in
the Jitsi area on Github and also publish it for Maven users.I don't mind making a first version of it if somebody can create a
Github repo and give me access, e.g. https://github.com/jitsi/uri-launcher
?
Then other people can contribute platform-specific things as pull
requests.
I don't see a problem with this. I'd prefer the project name to be prefixed
with Jitsi though, so that it's clear what it is when people clone it into
their own account. Can you start that in your own account and we'll move it
over to Jitsi once I get Emils consent?
I guess we'd be open to have some way to dynamically add an account,
e.g. by specifying the protocol provider factory and a set of properties
for the account. However, I guess the user would need to informed about
it and give his consent before actually installing the account.That type of popup seems quite OK
It is very constrained by the fact that the URI handler (invoked using
java.awt.Desktop.browse()) can only receive one argument, the URI. That
is why I suggest adding something as a URI parameter rather than a
regular command line parameter.
I don't think it really matters how it arrives in Jitsi as long as we can
extract it at a reasonable early stage.
Or maybe there can just be a URI parameter that hints to Jitsi that it
should create an anonymous SIP account without registrationThat doesn't sound to useful to me?
SIP does allow anonymous calls,
From: <anonymous@anonymous.invalid>
http://tools.ietf.org/html/rfc3323.html#section-4.1.1.3Some applications will be willing to accept anonymous calls and may use
some custom URI parameter to authenticate the user, much like web sites
use cookies instead of HTTP DIGEST
Creating a registrarless account would then hopefully be just the same as on
ordinary account (with different properties obviously).
One issue I notice trying this with Jitsi is that it always seems to try
UDP for accounts that don't register, even if the destination has a
NAPTR for TLS.
Hmm, yes. Can you please open a bug report for this on Trac and assign to
me?
Ingo
···
On 2014-08-01 19:28, Daniel Pocock wrote:
On 01/08/14 12:12, Ingo Bauersachs wrote:
On 2014-08-01 17:55, Daniel Pocock wrote:
On 01/08/14 11:37, Ingo Bauersachs wrote:
On 2014-08-01 02:06, Daniel Pocock wrote:
It is not specific to Jitsi - I've created it here:
https://github.com/opentelecoms-org/client-launch
and here is the Jitsi-finding logic:
Does it look correct for Windows?
Can anybody suggest how to tweak this for OS X and other platforms?
···
On 03/08/14 06:04, Ingo Bauersachs wrote:
On 2014-08-01 19:28, Daniel Pocock wrote:
On 01/08/14 12:12, Ingo Bauersachs wrote:
On 2014-08-01 17:55, Daniel Pocock wrote:
On 01/08/14 11:37, Ingo Bauersachs wrote:
On 2014-08-01 02:06, Daniel Pocock wrote:
We already pass arguments to an already running instance, so this
shouldn't be a problem. However finding a non-running one... I can't
think of a way other than searching the system for known paths. On
Windows the registry might help to check for the path of the xmpp: and
sip: handlers.I agree there is no convenient and precise way to do this. Maybe it is
possible to make a class that does this successfully for 80% of users
though.As the search would have to be done from outside of Jitsi, can we do
something else than to provide you with a list of known installationpaths?
Yes, I'm not asking you to provide a magic solution
It would be nice to create a JAR with this functionality and keep it in
the Jitsi area on Github and also publish it for Maven users.I don't mind making a first version of it if somebody can create a
Github repo and give me access, e.g. https://github.com/jitsi/uri-launcher?
Then other people can contribute platform-specific things as pull
requests.
I don't see a problem with this. I'd prefer the project name to be prefixed
with Jitsi though, so that it's clear what it is when people clone it into
their own account. Can you start that in your own account and we'll move it
over to Jitsi once I get Emils consent?
No, the Windows-part it too much simplified. C:\Program Files is not necessarily this name (can be Programme in German) or on another disk. Use the environment variable %ProgramFiles% for it. You're also missing the Jitsi-x86 installation on Windows-x64, which would be installed in %ProgramFiles(x86)% (yes, that is an env-var with parantheses).
Freundliche Grüsse,
Ingo Bauersachs
-- sent from my mobile
···
Le 08.08.2014 à 20:40, "Daniel Pocock" <daniel@pocock.pro> a écrit :
On 03/08/14 06:04, Ingo Bauersachs wrote:
On 2014-08-01 19:28, Daniel Pocock wrote:
On 01/08/14 12:12, Ingo Bauersachs wrote:
On 2014-08-01 17:55, Daniel Pocock wrote:
On 01/08/14 11:37, Ingo Bauersachs wrote:
On 2014-08-01 02:06, Daniel Pocock wrote:
We already pass arguments to an already running instance, so this
shouldn't be a problem. However finding a non-running one... I can't
think of a way other than searching the system for known paths. On
Windows the registry might help to check for the path of the xmpp: and
sip: handlers.I agree there is no convenient and precise way to do this. Maybe it is
possible to make a class that does this successfully for 80% of users
though.As the search would have to be done from outside of Jitsi, can we do
something else than to provide you with a list of known installationpaths?
Yes, I'm not asking you to provide a magic solution
It would be nice to create a JAR with this functionality and keep it in
the Jitsi area on Github and also publish it for Maven users.I don't mind making a first version of it if somebody can create a
Github repo and give me access, e.g. https://github.com/jitsi/uri-launcher?
Then other people can contribute platform-specific things as pull
requests.
I don't see a problem with this. I'd prefer the project name to be prefixed
with Jitsi though, so that it's clear what it is when people clone it into
their own account. Can you start that in your own account and we'll move it
over to Jitsi once I get Emils consent?It is not specific to Jitsi - I've created it here:
https://github.com/opentelecoms-org/client-launch
and here is the Jitsi-finding logic:
Does it look correct for Windows?
Can anybody suggest how to tweak this for OS X and other platforms?
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
Thanks for this feedback - I've updated it
···
On 08/08/14 17:49, Ingo Bauersachs wrote:
No, the Windows-part it too much simplified. C:\Program Files is not necessarily this name (can be Programme in German) or on another disk. Use the environment variable %ProgramFiles% for it. You're also missing the Jitsi-x86 installation on Windows-x64, which would be installed in %ProgramFiles(x86)% (yes, that is an env-var with parantheses).