web server for appstream metadata screenshots
Ben Cooksley
bcooksley at kde.org
Sun Jun 12 10:21:11 BST 2016
On Sun, Jun 12, 2016 at 4:46 PM, Yuri Chornoivan <yurchor at ukr.net> wrote:
> написане Sun, 12 Jun 2016 04:17:07 +0300, Albert Astals Cid <aacid at kde.org>:
>
>
>> El dimecres, 8 de juny de 2016, a les 19:32:32 CEST, Yuri Chornoivan va
>> escriure:
>>>
>>> написане Wed, 08 Jun 2016 19:27:23 +0300, Burkhard Lück
>>>
>>> <lueck at hube-lueck.de>:
>>> > Am Mittwoch, 8. Juni 2016, 12:45:13 CEST schrieb Nicolás Alvarez:
>>> >> 2016-06-08 8:33 GMT-03:00 Friedrich W. H. Kossebau <kossebau at kde.org>:
>>> >> > Am Mittwoch, 8. Juni 2016, 13:10:04 CEST schrieb Sebastian Kügler:
>>> >> >> Hey,
>>> >> >>
>>> >> >> I've been adding appstream metadata to one of the apps I maintain,
>>> >>
>>> >> among
>>> >>
>>> >> >> that are also screenshots, in the form of a URL. That means that I
>>> >>
>>> >> have
>>> >>
>>> >> >> to
>>> >> >> put the screenshots on a webserver.
>>> >> >>
>>> >> >> Do we already have a canonical location for these screenshots? If
>>> >>
>>> >> not,
>>> >>
>>> >> >> let's create one before we get people hosting them on imgur, their
>>> >> >> private webserver or their router-behind-a-dsl-line. :)
>>> >> >
>>> >> > Good idea, also when it comes to long-term availability of
>>> >> > referenced
>>> >> > images>
>>> >> >
>>> >> > :)
>>> >> >
>>> >> > It might make sense to reuse/share the screenshots with the ones
>>> >> > used
>>> >>
>>> >> for
>>> >>
>>> >> > the KDE app catalog we have at kde.org/applications/. For
>>> >> > consistency
>>> >>
>>> >> and
>>> >>
>>> >> > for efficiency.
>>> >> >
>>> >> > Not sure though what a stable url would be like, given people
>>> >>
>>> >> planning to
>>> >>
>>> >> > rework kde.org (and thus those app catalog pages), so perhaps
>>> >> > relying
>>> >>
>>> >> on
>>> >>
>>> >> > the current screenshot urls used by kde.org/applications is not
>>> >>
>>> >> perfect.
>>> >> The screenshots on kde.org/applications are stored in SVN and they are
>>> >> the main reason why I couldn't migrate that website to Git. I would
>>> >> prefer if you don't add even more there...
>>> >
>>> > www/sites/www/screenshots (svn) has 176 pngs
>>> >
>>> > websites/edu-kde-org/ (git) has 1287 pngs
>>> >
>>> > master kf5 / doc[s] (git) folders have 2079 pngs
>>> >
>>> > master kde4 / doc[s] (git) folders have 1702 pngs
>>> >
>>> > I do not understand why the 176 pngs in www/sites/www/screenshots are a
>>> > problem for migration to git
>>>
>>> Hi,
>>>
>>> I might be wrong, but is the hotlinking to Phabricator/Git files
>>> (screenshots in this case) a good thing?
>>
>>
>> Nobody suggested that, right?
>
>
Hi Yuri,
> I might misunderstand the whole thing. If it is, just ignore this message.
>
> The typical size of AppData screenshot is ~100 kB. Let's say that there are
> ~1000 users that use Discover features to explore KDE applications in a
> release day. They can overview ~10 screenshots in average. This will be 1 GB
> of traffic + load on Phabricator to resolve commits.kde.org links (if files
> are stored in git).
>
> Recently, Ben Cooksley removed the page with Calligra Icons from
> community.kde.org for similar hotlinking:
>
> https://community.kde.org/Calligra/Icons/3.0
>
> That was the source of my concerns.
The site www.kde.org isn't a repository browser - it is an actual
checkout of a section of the SVN repository, and is served with
minimal overhead as a result.
Note that traffic itself isn't a huge concern for sites that have a
minimal overhead, so i'm not concerned with using screenshots on
www.kde.org for appstream - at least in the short term.
I do ask that the urls to the images be easily changable in the future
(i'm guessing Appstream clients download metadata files, which have
the urls to the screenshots), and that if any outside party (such as
distributions) wishes to use those urls they do so with the
understanding that we may change them, at short notice, to a different
url.
The majority of our websites which are hosted in Git or SVN are setup
in this manner.
Sysadmin has always objected to hotlinking to repository browsers -
including quickgit.kde.org and websvn.kde.org.
>
> On the other hand, if screenshots will be stored in different
> places/hostings (each application stores its screenshot in its own place) it
> can leverage the load on our infrastructure.
>
> Sorry again, if I misunderstand something.
>
> Best regards,
> Yuri
Cheers,
Ben
More information about the kde-core-devel
mailing list