[
https://issues.apache.org/jira/browse/IGNITE-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513325#comment-14513325
]
Branko Čibej commented on IGNITE-775:
-------------------------------------
I really forget where the idea came from and/or who is currently using this; I
know I discussed this with various people years ago, and I'm sure it's being
used today.
Here's the outline: the more users you have, the more expensive your
infrastructure for update notifications becomes. Consider a phone app with 100
million users; with a bit of luck, you'll get at least that many hits per day
on your server just for version update checking. With a centralised server
using HTTPS for non-repudiation, that can become quite a burden. The obvious
solution is to use many such servers, but then you're faced with managing a
(geographically) decentralised database just to manage update notiifications.
By a happy chance, a massively distributed, cached, asynchronous key-value
database is already ubiquitous throughout the internet: it's called the Domain
Naming Service. In its simplest form, an update notification service would use
a machine-readable TXT record to publish the current latest version: e.g., in
BIND config file format:
{noformat}
current-version.ignite.apache.org. IN TXT "2.0.3
https://download/url/...";
{noformat}
The software would just do a periodic DNS lookup for that record, parse it,
compare the version number with its current version and take it from there; the
point is that the vast majority of lookups will only touch some local DNS
cache, not your master server.
In practice, you'd at least want to cryptographically sign the TXT record so
that clients can verify its authenticity. DNS has any number of nice features
that lets you tune notifications: record expiry time determines how often
clients actually see record updates, GEODNS lets you control regional
distribution of version updates as well as point clients directly to their
local distribution mirrors, etc. etc.
There are probably other tricks you can do, frankly I'm not all that familiar
with the more esoteric DNS black magic.
> Fix binaries naming.
> --------------------
>
> Key: IGNITE-775
> URL: https://issues.apache.org/jira/browse/IGNITE-775
> Project: Ignite
> Issue Type: Bug
> Components: build
> Affects Versions: sprint-2
> Reporter: Nikita Ivanov
> Assignee: Anton Vinogradov
> Fix For: sprint-4
>
>
> To summarize:
> - GridGain Enterprise Edition (e.g., gridgain-enterprise-foo-version.zip) is
> fine;
> - GridGain Community Edition (e.g., gridgain-community-foo-version.zip) is
> fine;
> - Apache Ignite binaries provided by GridGain (e.g.,
> apache-ignite-foo-version.zip) is fine, too, as long as the binaries don't go
> announcing version updates from info published on the GridGain site (but it's
> OK to look for info on the Ignite site); and as long as they either don't
> contain the LGPL&Co. dependencies, or very explicitly warn users that
> distribution rights are not covered by ALv2;
> What's currently published is confusing, i.e., not OK.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
