Purge support for index.xml and index.jar in fdroidclient

I’m thinking that the next release of F-Droid client should purge support for index.xml and index.jar. I would like feedback from all about what they think of this:

1 Like

Yeah, whatever, not sure I ever saw those.

In the context of the mobile landscape, 3 years is a lot of time to update ones installation of fdroidserver. So if it is a non-trivial inconvenience to support these old formats, I guess it would be a good choice to remove them now.

Are there any public fdroid repos that use them that anybody knows about?

I did a quick survey based on repo-monitor. Looks like only the tox repo is a concern, but they really should update anyway:

It’s not only about the fdroidserver versions in the repos. Some other tools utilizing the index might still be using the XML index. My repo browser eg does (not a concern here, since I could easily adjust; for my repo I’ve eg already switched to JSON for screenshots, I’d just need to add another option then to decide which repo to include screenshots for), and so might other tools.

Not sure if we have a way to check that. Maybe a poll via Mastodon? Not that wide coverage maybe, but still far better than none at all.

PS: One issue I have then is that F-Droid.org doesn’t ship the index-v1.json directly (only the JAR). Could the plain JSON be made available there then as well? If not, I’d have to rewrite the updater logic also.

Ugh, oh… Well, if I may name a show-stopper: My app-listings use the XML index for update checks and more. To rewrite that would be quite a crux, as it affects more than just that (other sources are sharing some logic, like Aptoide and Xposed which also use XML index). I cannot yet tell how much effort a rewrite would be; how long would I have for that?

This thread is only about removing support for index.xml and index.jar
from fdroidclient, nowhere else. I’m not proposing to drop
index.xml and index.jar from fdroidserver.

1 Like

Ugh… That’s a relief – and apologies for misinterpreting. The title clearly says so, and I was “concluding” to much luckily :stuck_out_tongue_closed_eyes:

Still: should I see this as “wake-up call”, and the same is planned for fdroidserver with just a little delay – or can I take your “not proposing” as-is (without appending “for now”)? In that case it cannot hurt to be prepared, and to “wake up the neighbors” as well…

I have no plans for removing those from fdroidserver, it seems
manageable there. But I think you’ll want to switch to index-v1.json
since it provides a lot more info, and in an easier format.

Actually I use my php-fdroid class as abstraction layer, so switching would really be that: flipping a switch. But doing so for f-droid.org would mean the detail pages loading slower and extra load for the source – as currently the only difference is that screenshots would be tried to load. Which we know is already an issue in fdroidclient depending on server load, so I wanted to avoid that.

But yes, it’s on my “list”: I have to implement a different switch for loading screenshots (currently it’s simply “XML = no images, JSON = images” – or more precisely, “if there are localized data”). The advantage would be localized summaries/descriptions for the fdroidorg repo (for my own, I already use the JSON).

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.