[jitsi-dev] Provisioning update link location


#1

Hi all,

we need to be able to provision the link to the versionupdate.properties
instead of having it hardcoded in the update-location.properties file. The
question is: how is it possible to find out which version of Jitsi is
currently running (x64 or x32) in order to correctly substitute the
@archValue part of the link in Java in a similar way it is done in ant
(using pre-set windows.arch.path). Would it be OK to completely rely on the
JVM that is being used and henceforth on the System.getProperty(
"sun.arch.data.model") property?

Regards,
Alexander Fedulov


#2

Hey Alexander,

You don't need that. Just place the x86 link in the version update
properties and make sure that both your x64 and x86 versions are at the
same location.

Jitsi will do the necessary conversions automatically.

Emil

···

On 20.11.12, 18:04, ijustwanttoregister@googlemail.com wrote:

Hi all,

we need to be able to provision the link to the versionupdate.properties
instead of having it hardcoded in the update-location.properties file.
The question is: how is it possible to find out which version of Jitsi
is currently running (x64 or x32) in order to correctly substitute the
@archValue part of the link in Java in a similar way it is done in ant
(using pre-set windows.arch.path). Would it be OK to completely rely on
the JVM that is being used and henceforth on
the System.getProperty("sun.arch.data.model") property?

Regards,
Alexander Fedulov

--
https://jitsi.org


#3

Hi Emil,

do you mean the following structure:

macos
windows
       1.0
       1.0.1
            Some_name_-1.0.1-x86.exe
            Some_name_-1.0.1-x64.exe
            updates
        versionupdate.properties

In this case I do not get how would an update work, if download_link
property from the versionupdate.properties file points to a specific file
to be dowloaded, like so:

last_version=1.0.1
download_link=http://…/windows/x86/1.0.1/Some_name_-1.0.1-x86.exe

As far as I can determine from the source code, it is crucial to have
update update_link property to point to different versionupdate.properties
files, depending on the architecture version. This is not a problem, if
every installation of Jitsi uses a pre-determined
update-location.properties file, which is already configured depending on
the installed version. We, however, want to be able to set that value
dynamically, based on a specific partner configuration by the means of
provisioning utilities (net.java.sip.communicator.UPDATE_LINK). So if my
line of thought is correct and our goals got a bit more clear I will
rephrase the question:

Is JVM architecture version seen from Jitsi (32bit/64 bit from
System.getProperty("os.arch") ) always equal to the architecture
of installed Jitsi or can there be some corner cases?

Just as a side note: the same property is used in the Update plugin for
Windows and in the Sparkle framework for MacOS, which renders it pretty
much useless if both OSes have to be supported (MacOS requires updates.xml
file rather than versionupdate.properties). We have added an
additional net.java.sip.communicator.MAC_UPDATE_LINK to circumvent that
difficulty.

Regards,
Alex

···

2012/11/21 Emil Ivov <emcho@jitsi.org>

Hey Alexander,

You don't need that. Just place the x86 link in the version update
properties and make sure that both your x64 and x86 versions are at the
same location.

Jitsi will do the necessary conversions automatically.

Emil

On 20.11.12, 18:04, ijustwanttoregister@googlemail.com wrote:
> Hi all,
>
> we need to be able to provision the link to the versionupdate.properties
> instead of having it hardcoded in the update-location.properties file.
> The question is: how is it possible to find out which version of Jitsi
> is currently running (x64 or x32) in order to correctly substitute the
> @archValue part of the link in Java in a similar way it is done in ant
> (using pre-set windows.arch.path). Would it be OK to completely rely on
> the JVM that is being used and henceforth on
> the System.getProperty("sun.arch.data.model") property?
>
> Regards,
> Alexander Fedulov

--
https://jitsi.org


#4

Hey Alex,

Hi Emil,

do you mean the following structure:

macos
windows
       1.0
       1.0.1
            Some_name_-1.0.1-x86.exe
            Some_name_-1.0.1-x64.exe
            updates
        versionupdate.properties

In this case I do not get how would an update work, if download_link
property from the versionupdate.properties file points to a specific
file to be dowloaded, like so:

last_version=1.0.1
download_link=http://…/windows/x86/1.0.1/Some_name_-1.0.1-x86.exe

The Jitsi updater on an x64 platform would just get the above link and
replace the x86 with x64, then try to get the binary at the newly
obtained address.

As far as I can determine from the source code, it is crucial to have
update update_link property to point to different
versionupdate.properties files, depending on the architecture version.
This is not a problem, if every installation of Jitsi uses a
pre-determined update-location.properties file, which is already
configured depending on the installed version. We, however, want to be
able to set that value dynamically, based on a specific partner
configuration by the means of provisioning utilities
(net.java.sip.communicator.UPDATE_LINK).

I am not sure I understand what your problem is. The update link just
points to the update root location. We append the OS to that location.
The link that's in versionupdate.properties then points to the actual 32
bit binary on windows and we simply expect to find the 64bit location
next to it.

So if my line of thought is
correct and our goals got a bit more clear I will rephrase the question:

Is JVM architecture version seen from Jitsi (32bit/64 bit from
System.getProperty("os.arch") ) always equal to the architecture
of installed Jitsi or can there be some corner cases?

Jitsi will always update itself to the same arch that it is currently
running.

In case you are running a 32 bit installation on a 64 bit OS, it may
notify you that a better option exists but that would only be during the
first installation.

Just as a side note: the same property is used in the Update plugin for
Windows and in the Sparkle framework for MacOS, which renders it pretty
much useless if both OSes have to be supported (MacOS requires
updates.xml file rather than versionupdate.properties). We have added an
additional net.java.sip.communicator.MAC_UPDATE_LINK to circumvent that
difficulty.

Not following. Why would it be useless? That's how we are currently
using it. The UPDATE_LINK just points to the root, you then simply need
to create "windows" and "macosx" directories where Jitsi will look for
more info depending on the system it is running on.

This way a provisioning server doesn't have to care about the OS and
arch of a client when feeding them the update URL.

Emil

···

On 21.11.12, 16:14, ijustwanttoregister@googlemail.com wrote:

Regards,
Alex

2012/11/21 Emil Ivov <emcho@jitsi.org <mailto:emcho@jitsi.org>>

    Hey Alexander,

    You don't need that. Just place the x86 link in the version update
    properties and make sure that both your x64 and x86 versions are at the
    same location.

    Jitsi will do the necessary conversions automatically.

    Emil

    On 20.11.12, 18:04, ijustwanttoregister@googlemail.com > <mailto:ijustwanttoregister@googlemail.com> wrote:
    > Hi all,
    >
    > we need to be able to provision the link to the
    versionupdate.properties
    > instead of having it hardcoded in the update-location.properties file.
    > The question is: how is it possible to find out which version of Jitsi
    > is currently running (x64 or x32) in order to correctly substitute the
    > @archValue part of the link in Java in a similar way it is done in ant
    > (using pre-set windows.arch.path). Would it be OK to completely
    rely on
    > the JVM that is being used and henceforth on
    > the System.getProperty("sun.arch.data.model") property?
    >
    > Regards,
    > Alexander Fedulov

    --
    https://jitsi.org

--
https://jitsi.org


#5

Hi Emil,

there was some confusion caused by the fact that those @archValue part of
the update link was an undocumented change introduced by my colleague, who
did not take into account the procedures for x86->x64 manipulations in the
windows updater class. Sorry for that.

I made some checks and still cannot figure out how provisioning
net.java.sip.communicator.UPDATE_LINK (used as the PROP_UPDATE_LINK
) would work for both windows and macosx.
In windows updater plugin, the link is first attempted to be obtained from
the provisioned properties first. If it is not defined there, it is
gathered from of the update-location.properties file. In SparkleActivator,
however, this link is only attempted to be fetched from
the ConfigurationService. It is then forwarded as a parameter of the native
call API to the Sparkle framework. This downloadLink is not manipulated
anywhere in the code before being passed to sparkle. For me it only works
if the link directly points to the full path of the updates file, like so:
http://hostname.com/projectname/macosx/update.xml. Specifying only the the
root folder http://hostname.com/projectname/ breaks the updates for both
windows and macosx.

Regards,
Alex

···

2012/11/21 Emil Ivov <emcho@jitsi.org>

Hey Alex,

On 21.11.12, 16:14, ijustwanttoregister@googlemail.com wrote:
> Hi Emil,
>
> do you mean the following structure:
>
> macos
> windows
> 1.0
> 1.0.1
> Some_name_-1.0.1-x86.exe
> Some_name_-1.0.1-x64.exe
> updates
> versionupdate.properties
>
> In this case I do not get how would an update work, if download_link
> property from the versionupdate.properties file points to a specific
> file to be dowloaded, like so:
>
> last_version=1.0.1
> download_link=http://…/windows/x86/1.0.1/Some_name_-1.0.1-x86.exe

The Jitsi updater on an x64 platform would just get the above link and
replace the x86 with x64, then try to get the binary at the newly
obtained address.

> As far as I can determine from the source code, it is crucial to have
> update update_link property to point to different
> versionupdate.properties files, depending on the architecture version.
> This is not a problem, if every installation of Jitsi uses a
> pre-determined update-location.properties file, which is already
> configured depending on the installed version. We, however, want to be
> able to set that value dynamically, based on a specific partner
> configuration by the means of provisioning utilities
> (net.java.sip.communicator.UPDATE_LINK).

I am not sure I understand what your problem is. The update link just
points to the update root location. We append the OS to that location.
The link that's in versionupdate.properties then points to the actual 32
bit binary on windows and we simply expect to find the 64bit location
next to it.

> So if my line of thought is
> correct and our goals got a bit more clear I will rephrase the question:
>
> Is JVM architecture version seen from Jitsi (32bit/64 bit from
> System.getProperty("os.arch") ) always equal to the architecture
> of installed Jitsi or can there be some corner cases?

Jitsi will always update itself to the same arch that it is currently
running.

In case you are running a 32 bit installation on a 64 bit OS, it may
notify you that a better option exists but that would only be during the
first installation.

> Just as a side note: the same property is used in the Update plugin for
> Windows and in the Sparkle framework for MacOS, which renders it pretty
> much useless if both OSes have to be supported (MacOS requires
> updates.xml file rather than versionupdate.properties). We have added an
> additional net.java.sip.communicator.MAC_UPDATE_LINK to circumvent that
> difficulty.

Not following. Why would it be useless? That's how we are currently
using it. The UPDATE_LINK just points to the root, you then simply need
to create "windows" and "macosx" directories where Jitsi will look for
more info depending on the system it is running on.

This way a provisioning server doesn't have to care about the OS and
arch of a client when feeding them the update URL.

Emil
>
> Regards,
> Alex
>
> 2012/11/21 Emil Ivov <emcho@jitsi.org <mailto:emcho@jitsi.org>>
>
> Hey Alexander,
>
> You don't need that. Just place the x86 link in the version update
> properties and make sure that both your x64 and x86 versions are at
the
> same location.
>
> Jitsi will do the necessary conversions automatically.
>
> Emil
>
> On 20.11.12, 18:04, ijustwanttoregister@googlemail.com > > <mailto:ijustwanttoregister@googlemail.com> wrote:
> > Hi all,
> >
> > we need to be able to provision the link to the
> versionupdate.properties
> > instead of having it hardcoded in the update-location.properties
file.
> > The question is: how is it possible to find out which version of
Jitsi
> > is currently running (x64 or x32) in order to correctly substitute
the
> > @archValue part of the link in Java in a similar way it is done in
ant
> > (using pre-set windows.arch.path). Would it be OK to completely
> rely on
> > the JVM that is being used and henceforth on
> > the System.getProperty("sun.arch.data.model") property?
> >
> > Regards,
> > Alexander Fedulov
>
> --
> https://jitsi.org
>
>

--
https://jitsi.org


#6

Hey Alex,

Hi Emil,

there was some confusion caused by the fact that those @archValue part
of the update link was an undocumented change introduced by my
colleague, who did not take into account the procedures for x86->x64
manipulations in the windows updater class. Sorry for that.

My turn to apologize. It seems that I was reporting the wrong behaviour.
We do indeed have a single link for both OSes:

net.java.sip.communicator.UPDATE_LINK

You should set it to either versionupdate.properties or sparkle/updates.xml

Your provisioning server would have to make the decision depending on
the client, which also means that the OS would have to be reported in
the original provisioning query.

I still think a single link would work better, so if you feel like it:
please open an issue.

I apologise again for the confusion. Not sure what I was thinking.

Cheers,
Emil

···

On 22.11.12, 17:24, ijustwanttoregister@googlemail.com wrote:

I made some checks and still cannot figure out how provisioning
net.java.sip.communicator.UPDATE_LINK (used as the PROP_UPDATE_LINK
) would work for both windows and macosx.
In windows updater plugin, the link is first attempted to be obtained
from the provisioned properties first. If it is not defined there, it
is gathered from of the update-location.properties file. In
SparkleActivator, however, this link is only attempted to be fetched
from the ConfigurationService. It is then forwarded as a parameter of
the native call API to the Sparkle framework. This downloadLink is not
manipulated anywhere in the code before being passed to sparkle. For me
it only works if the link directly points to the full path of the
updates file, like so:
http://hostname.com/projectname/macosx/update.xml. Specifying only the
the root folder http://hostname.com/projectname/ breaks the updates for
both windows and macosx.

Regards,
Alex

2012/11/21 Emil Ivov <emcho@jitsi.org <mailto:emcho@jitsi.org>>

    Hey Alex,

    On 21.11.12, 16:14, ijustwanttoregister@googlemail.com > <mailto:ijustwanttoregister@googlemail.com> wrote:
    > Hi Emil,
    >
    > do you mean the following structure:
    >
    > macos
    > windows
    > 1.0
    > 1.0.1
    > Some_name_-1.0.1-x86.exe
    > Some_name_-1.0.1-x64.exe
    > updates
    > versionupdate.properties
    >
    > In this case I do not get how would an update work, if download_link
    > property from the versionupdate.properties file points to a specific
    > file to be dowloaded, like so:
    >
    > last_version=1.0.1
    > download_link=http://…/windows/x86/1.0.1/Some_name_-1.0.1-x86.exe

    The Jitsi updater on an x64 platform would just get the above link and
    replace the x86 with x64, then try to get the binary at the newly
    obtained address.

    > As far as I can determine from the source code, it is crucial to have
    > update update_link property to point to different
    > versionupdate.properties files, depending on the architecture version.
    > This is not a problem, if every installation of Jitsi uses a
    > pre-determined update-location.properties file, which is already
    > configured depending on the installed version. We, however, want to be
    > able to set that value dynamically, based on a specific partner
    > configuration by the means of provisioning utilities
    > (net.java.sip.communicator.UPDATE_LINK).

    I am not sure I understand what your problem is. The update link just
    points to the update root location. We append the OS to that location.
    The link that's in versionupdate.properties then points to the actual 32
    bit binary on windows and we simply expect to find the 64bit location
    next to it.

    > So if my line of thought is
    > correct and our goals got a bit more clear I will rephrase the
    question:
    >
    > Is JVM architecture version seen from Jitsi (32bit/64 bit from
    > System.getProperty("os.arch") ) always equal to the architecture
    > of installed Jitsi or can there be some corner cases?

    Jitsi will always update itself to the same arch that it is currently
    running.

    In case you are running a 32 bit installation on a 64 bit OS, it may
    notify you that a better option exists but that would only be during the
    first installation.

    > Just as a side note: the same property is used in the Update
    plugin for
    > Windows and in the Sparkle framework for MacOS, which renders it
    pretty
    > much useless if both OSes have to be supported (MacOS requires
    > updates.xml file rather than versionupdate.properties). We have
    added an
    > additional net.java.sip.communicator.MAC_UPDATE_LINK to circumvent
    that
    > difficulty.

    Not following. Why would it be useless? That's how we are currently
    using it. The UPDATE_LINK just points to the root, you then simply need
    to create "windows" and "macosx" directories where Jitsi will look for
    more info depending on the system it is running on.

    This way a provisioning server doesn't have to care about the OS and
    arch of a client when feeding them the update URL.

    Emil
    >
    > Regards,
    > Alex
    >
    > 2012/11/21 Emil Ivov <emcho@jitsi.org <mailto:emcho@jitsi.org>
    <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>
    >
    > Hey Alexander,
    >
    > You don't need that. Just place the x86 link in the version update
    > properties and make sure that both your x64 and x86 versions
    are at the
    > same location.
    >
    > Jitsi will do the necessary conversions automatically.
    >
    > Emil
    >
    > On 20.11.12, 18:04, ijustwanttoregister@googlemail.com > <mailto:ijustwanttoregister@googlemail.com> > > <mailto:ijustwanttoregister@googlemail.com > <mailto:ijustwanttoregister@googlemail.com>> wrote:
    > > Hi all,
    > >
    > > we need to be able to provision the link to the
    > versionupdate.properties
    > > instead of having it hardcoded in the
    update-location.properties file.
    > > The question is: how is it possible to find out which
    version of Jitsi
    > > is currently running (x64 or x32) in order to correctly
    substitute the
    > > @archValue part of the link in Java in a similar way it is
    done in ant
    > > (using pre-set windows.arch.path). Would it be OK to completely
    > rely on
    > > the JVM that is being used and henceforth on
    > > the System.getProperty("sun.arch.data.model") property?
    > >
    > > Regards,
    > > Alexander Fedulov
    >
    > --
    > https://jitsi.org
    >
    >

    --
    https://jitsi.org

--
https://jitsi.org


#7

Hi Emil,

no problem and thanks for the clarifications.

We will stick to provisioning two separate update links - one for mac and
one for windows.

Regards,
Alexander Fedulov

···

2012/11/23 Emil Ivov <emcho@jitsi.org>

Hey Alex,

On 22.11.12, 17:24, ijustwanttoregister@googlemail.com wrote:
> Hi Emil,
>
> there was some confusion caused by the fact that those @archValue part
> of the update link was an undocumented change introduced by my
> colleague, who did not take into account the procedures for x86->x64
> manipulations in the windows updater class. Sorry for that.

My turn to apologize. It seems that I was reporting the wrong behaviour.
We do indeed have a single link for both OSes:

net.java.sip.communicator.UPDATE_LINK

You should set it to either versionupdate.properties or sparkle/updates.xml

Your provisioning server would have to make the decision depending on
the client, which also means that the OS would have to be reported in
the original provisioning query.

I still think a single link would work better, so if you feel like it:
please open an issue.

I apologise again for the confusion. Not sure what I was thinking.

Cheers,
Emil
>
> I made some checks and still cannot figure out how provisioning
> net.java.sip.communicator.UPDATE_LINK (used as the PROP_UPDATE_LINK
> ) would work for both windows and macosx.
> In windows updater plugin, the link is first attempted to be obtained
> from the provisioned properties first. If it is not defined there, it
> is gathered from of the update-location.properties file. In
> SparkleActivator, however, this link is only attempted to be fetched
> from the ConfigurationService. It is then forwarded as a parameter of
> the native call API to the Sparkle framework. This downloadLink is not
> manipulated anywhere in the code before being passed to sparkle. For me
> it only works if the link directly points to the full path of the
> updates file, like so:
> http://hostname.com/projectname/macosx/update.xml. Specifying only the
> the root folder http://hostname.com/projectname/ breaks the updates for
> both windows and macosx.
>
> Regards,
> Alex
>
> 2012/11/21 Emil Ivov <emcho@jitsi.org <mailto:emcho@jitsi.org>>
>
> Hey Alex,
>
> On 21.11.12, 16:14, ijustwanttoregister@googlemail.com > > <mailto:ijustwanttoregister@googlemail.com> wrote:
> > Hi Emil,
> >
> > do you mean the following structure:
> >
> > macos
> > windows
> > 1.0
> > 1.0.1
> > Some_name_-1.0.1-x86.exe
> > Some_name_-1.0.1-x64.exe
> > updates
> > versionupdate.properties
> >
> > In this case I do not get how would an update work, if
download_link
> > property from the versionupdate.properties file points to a
specific
> > file to be dowloaded, like so:
> >
> > last_version=1.0.1
> > download_link=http://
.../windows/x86/1.0.1/Some_name_-1.0.1-x86.exe
>
> The Jitsi updater on an x64 platform would just get the above link
and
> replace the x86 with x64, then try to get the binary at the newly
> obtained address.
>
> > As far as I can determine from the source code, it is crucial to
have
> > update update_link property to point to different
> > versionupdate.properties files, depending on the architecture
version.
> > This is not a problem, if every installation of Jitsi uses a
> > pre-determined update-location.properties file, which is already
> > configured depending on the installed version. We, however, want
to be
> > able to set that value dynamically, based on a specific partner
> > configuration by the means of provisioning utilities
> > (net.java.sip.communicator.UPDATE_LINK).
>
> I am not sure I understand what your problem is. The update link just
> points to the update root location. We append the OS to that
location.
> The link that's in versionupdate.properties then points to the
actual 32
> bit binary on windows and we simply expect to find the 64bit location
> next to it.
>
> > So if my line of thought is
> > correct and our goals got a bit more clear I will rephrase the
> question:
> >
> > Is JVM architecture version seen from Jitsi (32bit/64 bit from
> > System.getProperty("os.arch") ) always equal to the architecture
> > of installed Jitsi or can there be some corner cases?
>
> Jitsi will always update itself to the same arch that it is currently
> running.
>
> In case you are running a 32 bit installation on a 64 bit OS, it may
> notify you that a better option exists but that would only be during
the
> first installation.
>
> > Just as a side note: the same property is used in the Update
> plugin for
> > Windows and in the Sparkle framework for MacOS, which renders it
> pretty
> > much useless if both OSes have to be supported (MacOS requires
> > updates.xml file rather than versionupdate.properties). We have
> added an
> > additional net.java.sip.communicator.MAC_UPDATE_LINK to circumvent
> that
> > difficulty.
>
> Not following. Why would it be useless? That's how we are currently
> using it. The UPDATE_LINK just points to the root, you then simply
need
> to create "windows" and "macosx" directories where Jitsi will look
for
> more info depending on the system it is running on.
>
> This way a provisioning server doesn't have to care about the OS and
> arch of a client when feeding them the update URL.
>
> Emil
> >
> > Regards,
> > Alex
> >
> > 2012/11/21 Emil Ivov <emcho@jitsi.org <mailto:emcho@jitsi.org>
> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>
> >
> > Hey Alexander,
> >
> > You don't need that. Just place the x86 link in the version
update
> > properties and make sure that both your x64 and x86 versions
> are at the
> > same location.
> >
> > Jitsi will do the necessary conversions automatically.
> >
> > Emil
> >
> > On 20.11.12, 18:04, ijustwanttoregister@googlemail.com > > <mailto:ijustwanttoregister@googlemail.com> > > > <mailto:ijustwanttoregister@googlemail.com > > <mailto:ijustwanttoregister@googlemail.com>> wrote:
> > > Hi all,
> > >
> > > we need to be able to provision the link to the
> > versionupdate.properties
> > > instead of having it hardcoded in the
> update-location.properties file.
> > > The question is: how is it possible to find out which
> version of Jitsi
> > > is currently running (x64 or x32) in order to correctly
> substitute the
> > > @archValue part of the link in Java in a similar way it is
> done in ant
> > > (using pre-set windows.arch.path). Would it be OK to
completely
> > rely on
> > > the JVM that is being used and henceforth on
> > > the System.getProperty("sun.arch.data.model") property?
> > >
> > > Regards,
> > > Alexander Fedulov
> >
> > --
> > https://jitsi.org
> >
> >
>
> --
> https://jitsi.org
>
>

--
https://jitsi.org