Never ask for confirmations. It's never the right thing to do unless
you're very short of resources, which we never are these days.
Instead, provide an undo of a layer delete. When they ask to delete a
layer that has changes in it, simply delete it, and pop up a
non-confirmation notice that says
> > - Ideally, operating systems should ship with a happy eyeballs implementati
> on
> > in the C library. I don't know any that does. It is not such a great idea
> > for applications to roll their own. Mostly because you may want knobs to
> > configure things system wide.
>
> For C there
On Fri, 1 Jan 2016, Philip Homburg wrote:
- Ideally, operating systems should ship with a happy eyeballs implementation
in the C library. I don't know any that does. It is not such a great idea
for applications to roll their own. Mostly because you may want knobs to
configure things system
On Fri, 1 Jan 2016, Philip Homburg wrote:
It is really simple. An application should do nothing more than trying each
address in turn in the order returned by getaddrinfo. Either connect(2)
succeeds and you are done or there is a failure and you try the next address.
That does cause large
Hi!
On Fri, Jan 1, 2016 at 12:47 AM, Florian Lohoff wrote:
> There is no such thing as a on-the-fly detection. You as the application
> author need to write the detection. You need robust "connect" logic
> which tries ipv6 and falls back to ipv4 when the connect does not
> work. The
On Fri, 1 Jan 2016, Simon Legner wrote:
I tried to find some reference implementations for the RFC6555 / Happy
Eyeballs in Java – without success. None of the popular HTTP client
libraries [1, 2, 3] seem to have any support for this algorithm.
Instead, they seem to attempt connections
On Fri, 1 Jan 2016, Florian Lohoff wrote:
There are too few users with that specific issue to care for them
right now with an automatic approach.
Germany - Bigges Community - Largest ISP Telekom is switching all
DSL contracts to Dualstack. Kabel Deutschland is already handing
out IPv6 be
On Fri, Jan 01, 2016 at 01:09:30PM +0100, Simon Legner wrote:
> Hi!
>
> On Fri, Jan 1, 2016 at 12:47 AM, Florian Lohoff wrote:
> > So please - either fix ipv6 in JOSM by implementing the BCPs or
> > drop the ipv6 support completely - Currently you are breaking tons
> > of user setups
> may work or not" then it's ok when a provider only delivers data
> to half of the world? Well, why pay money for devlivery the other
> half?
>
> A network access which has permanent connectivity issues is broken!
>
> If you go into the future you will have IPv6 only. No IPv4 fallback.
> And it
I'm in favor of a way that allows to undo layer specific actions. But
to have a separate history stack per layer doesn't work well. Example:
An OSM data layer, a GPX layer, and a geotagged image
layer are open. The data layer is active and the images are correlated
to the GPX track. That
10 matches
Mail list logo