Feature Request: 'fork' for connection data

[lebochequirit]

I thought about that for a while and have seen it now in the tt-rss app available on f-droid:

The happ has "normal" connection data - let's say via https://owncloud.mydomain.tld

And for a certain Wifi connection (identified by SSID and one or more MACs) I have another connection via https://192.168.xxx.yyy.

The idea is not to route data via internet while I'm at home and can connect via LAN.

[davivel]

Any suggestion about how to solve it? I don't think we have time to check tt-rss. Are you thinking about letting the user explicitly define what URLs should be used for the same account depending on the network availability? Or am I losing some way to recognize it automatically from the app?

[lebochequirit]

It's the second. tt-rss has a settings entry for "connection" - which is the standard connection, ie. https://homevia.dyndns.org/owncloudinstall.
Then it has a tab "per-network-settings" where you can pick the actual Wifi network and then define another connection address, ie. https://192.168.xxx.yyy/owncloudinstall likewise the standard connection.
In effect, if you are at home, identified by ssid and MAC, owncloud will connect to https://192.168.xxx/owncloudinstall, else the client connects via https://homevia.dyndns.org/owncloudinstall

Picking the actual network is handy, but letting the user enter a certain SSID/MAC combination would be better for people running more than one network with the same SSID on different places.

Cheers,

L.B.Q.R.

[davivel]

This seems very, very interesting for tech-savvy users.

[jancborchardt]

This sounds like »LAN sync« similar to the one on the desktop app? owncloud/client#230

[davivel]

Not so sure; maybe to owncloud/mirall/#203 ?

[zatricky]

While it might achieve the same as LAN sync its not quite the same thing. The LAN sync proposal is completely automatic and could, in theory, be between clients as well as the server - but it only specifically relates to connectivity for upload/download, not to authentication and client configuration. The two can either work together or actually conflict in their aims, depending on the direction the Devs want to go.

This is sortof a duplicate of owncloud/client#203 - not sure if, because it is in /android/ that it should simply be linked rather than duped.

As noted in that issue, depending on how sophisticated your network infrastructure is, you can achieve this via DNS. For example, on my network, a DNS lookup for my server's public name gives the A record referring to 192.168.x.y, whereas the same lookup from outside gives a CNAME result referring to a dyndns-type record.

[zatricky]

@michaelstingl Please put a reason for it being closed - for example inactivity/implemented/duplicate/wontfix/etc
Thank you

[michaelstingl]

@zatricky Thanks for asking. I don't see a realistic chance to get this implemented from the ownCloud team in the near or mid-future. In case of a contribution, we can always re-open it. Nobody contributed to it in the last years and there are also no bounties for it:
https://www.bountysource.com/issues/1386463-feature-request-fork-for-connection-data

Please also check my comment about dnsmasq : owncloud/client#203 (comment)