Re: [josm-dev] How to ask for confirmation at layer deletion or exit?

[Russ Nelson]

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 "This layer has changes and may be
restored using File/Open Recent".

The problem with a confirmation is that it *really* deletes the data,
which may be the wrong thing. If you're ever at a confirmation point,
clearly somebody might not be thinking correctly, and their answer to
the confirmation might *also* be wrong.

Undo, undo, undo! Never confirm!

Holger Mappt writes:
 > Hi,
 > 
 > See https://josm.openstreetmap.de/ticket/12075.
 > The idea is to ask for confirmation if a GeoImageLayer with modified 
 > image properties is deleted.  What is the best/right way to do that?
 > 
 > The AbstractModifiableLayer seems to serve that purpose.  GeoImageLayer 
 > could extend AbstractModifiableLayer instead of Layer.  But there is not 
 > a single file associated with the layer but one file per modified image. 
 >   There is not really a "recommended action" for the SaveLayersDialog. 
 > The AbstractModifiableLayer would need to be extended to have something 
 > like isAbleToUploadToServer() and isAbleToSaveToFile() to disable the 
 > according check-boxes of the SaveLayersDialog.  The logic in 
 > Main.saveUnsavedModifications() would need to be changed to consider the 
 > layer if neither requiresSaveToFile() nor requiresUploadToServer() 
 > returns true.  Would it make sense to add something like 
 > requiresSomeAction() to AbstractModifiableLayer and 
 > Main.saveUnsavedModifications()?  The "action" could be a string that is 
 > displayed in the SaveLayersDialog.
 > 
 > Thanks,
 > Holger
 > 
 > ___
 > josm-dev mailing list
 > josm-dev@openstreetmap.org
 > https://lists.openstreetmap.org/listinfo/josm-dev

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Philip Homburg]

> > - 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 probably are libraries.

Yes, but if they are non-standard it is unlikely that java will pick them up.
And it should be a standard library for the OS. Having multiple libraries
increases the pain if you need to configure something.

> > - All applications should loop over all addresses returned by getaddrinfo.
> >  There is simply no excuse not to. If java makes it impossible to iterate
> >  over all addresses that it is java that is horribly broken.
> 
> And it's not so easy to handle multiple connects. You can either
> optimize for speed (open multiple connections parallel) or for load
> (open one after the other) or ignore it (single connect) or randomly
> choose an address (e.g. what postfix does). All of these methods
> have advantages and disadvantages and depend on the application.

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.

Trying to open connections in parallel enters happy eyeballs teritory.
Experience shows that it is hard to get right, so it is better to leave that
to a system library.

Note that happy eyeballs is only required if the first address causes a
timeout most of the time. Otherwise, it is much better have have to sit
through the occasional timeout than the have an application that gives up
after trying just the first address.

Trying only one address has been bad practice since before IPv6 was even
invented.

Of course, tweaking /etc/gai.conf to prefer IPv4 over IPv6 is also an option.
(Assuming java uses getaddrinfo under the hood)

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

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 wide.


For C there probably are libraries.


- All applications should loop over all addresses returned by getaddrinfo.
 There is simply no excuse not to. If java makes it impossible to iterate
 over all addresses that it is java that is horribly broken.


I disagree here. ATM most services only have one IPv4 address. In the 
transition time between protocols many will have IPv4 AND IPv6 but in the 
near future (let's say 5-10 years) most will either have IPv4 OR IPv6 and 
dual stack will slowly fade out.


And it's not so easy to handle multiple connects. You can either optimize 
for speed (open multiple connections parallel) or for load (open one after 
the other) or ignore it (single connect) or randomly choose an address 
(e.g. what postfix does). All of these methods have advantages and 
disadvantages and depend on the application.


And it's not so easy to decide when a connection works or not, as it can 
fail on multiple levels and so on and so on. Many programs are extremely 
simple and implementing a full featured we-try-all network access is total 
overkill. So also in the future the majority of tools will only open one 
connection and try once. It's wishful thinking to assume otherwise.


For our company applications it took me a lot of time and experience to 
create a non-blocking non-threading portable C network library to cope 
with the many existing issues. I know how much work that involves both in 
the application and the libraries.


Thus the main question here is if parallel connects are important 
enough, so that JOSM needs to support that feature or not. Currently I 
think not.


We have a number of network issues with the Java network code beside the 
rather ugly IPv6 handling and maybe in the future we'll replace it with 
another library and maybe that will include algorithms for multiple 
connects. The question already came up in a recent ticket. But that's a 
lot of work and also does not magically solve all the problems.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

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 timeouts in todays internet where packets are often 
dropped and not rejected. This is no option for JOSM in that easy 
configuration. To get it working an implementation must be more complex.



Trying only one address has been bad practice since before IPv6 was even
invented.


I disagree.


Of course, tweaking /etc/gai.conf to prefer IPv4 over IPv6 is also an option.
(Assuming java uses getaddrinfo under the hood)


Sadly Java does not follow this, but only has an option to say in advance 
whether IPv6 or IPv4 addresses should be preferred. And then it follows 
that rule ignoring the OS and the fact whether it works or not. And you 
cannot change this without a restart of the tool.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Simon Legner]

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 latest RFCs gives even more advice on how to work around
> long delays induced by servers advertising ipv6 and not responding
> to it or intermitted ipv6 problems e.g. packet loss in the v6 path. This
> is the daily business for an ISP - You path are different for v4 than
> for v6 so you have different latencys, paths, packet loss probabilities
> etc.

> 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 and you actively blame ipv6 for it.

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 sequentially to the resolved
addresses [4, 5].

On GitHub I could only find two Java demo projects on the
java.net.Socket level [6, 7].

Best regards,
Simon

[1] https://github.com/apache/httpclient
[2] https://github.com/eclipse/jetty.project
[3] https://github.com/square/okhttp/issues/506
[4] 
https://github.com/apache/httpclient/blob/be46d7fd93c7e3e576d739bb3ef40f4d2cf5e491/httpclient/src/main/java/org/apache/http/impl/conn/DefaultHttpClientConnectionOperator.java#L97-L171
[5] 
https://github.com/eclipse/jetty.project/blob/915a905df4dc19234938111095ea659b5deae5ce/jetty-client/src/main/java/org/eclipse/jetty/client/HttpClient.java#L538-L580
[6] 
https://github.com/ecki/IPv6Con/blob/master/src/main/java/net/eckenfels/ipv6con/SampleHappyEyeballs.java
[7] https://github.com/guinamen/Java-Happy-Eyeballs

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

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 sequentially to the resolved
addresses [4, 5].


Beside browsers nearly no software uses Happy Eyeballs as far as I know. 
Most software only does a single connect for a single IP. Some rotate the 
IP's, so each attempt tries another one. Some try one after another and so 
on.


All of these multi-connect mechanisms are workarounds. E.g. what do you do 
when you have a bad setup, where IPv6 connection is fine, but goes to the 
wrong destination. When do you decide that IPv4 must be used in this case.


That was a scenario I did see some often years ago with umanaged IPv6 
setups and service moving to another server without changing also the IPv6 
address.


Opening a TCP connection can become extremely complex when you want to 
care for all the possible misconfigurations.


We did not add multi-connect attempts for IPv4 only networks, why should 
we do it now? All IPv6 cases we had until now have been clearly broken 
connectivity. We can spend a lot of time to hide these errors, but what's 
the result? Will the users fix their setup? No.


I know these issues from 8 years ago when I started support for IPv6. 
Broken setups, providers not monitoring outages of IPv6, broken routes, 
... It's 8 years later now! You can buy working IPv6 connectivity. I don't 
see such IPv6 specific errors anymore today. Hiding the errors which 
occur with other providers wont help in my eyes - only fixing them is 
right.


BTW the stats say: Google has 10% IPv6 now. We have about 2%. I'd say it 
works when I compare this to other HTTP based services which I run which 
are in the 0.x% range still.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

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 default with DS Light. So within a very short timeframe
you'll see a lot more people complaining.


No. Because only a minority will walk between IPv6-enabled and IPv4-only 
networks.



Java does not support on-the-fly detection, but this setting must be
done before first network usage and cannot be changed later. We
can't change that behaviour. Feel free to submit a Java bug report.


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 latest RFCs gives even more advice on how to work around
long delays induced by servers advertising ipv6 and not responding
to it or intermitted ipv6 problems e.g. packet loss in the v6 path. This
is the daily business for an ISP - You path are different for v4 than
for v6 so you have different latencys, paths, packet loss probabilities
etc.


As said: We don't provide Happy Eyeballs. WHY should JOSM try to resolve 
the issues of the ISP? Loss on the path, delays, ... are all ISP issues 
and have to be solved by the ISP. Happy eyeballs only hides them.


The only valid argument ATM is that JOSM needs one additional start when 
you switch from an IPv6 enabled network to a non-enabled network. That's a 
known bug. And as said the reason is that Java does not allow us to change 
behaviour after we did a first network connection. I'll check if we can at 
least auto-restart it in this case.



My user setup is continously broken and i work around it. YOU refuse
to even implement 20 year old Best Common Practices written in RFCs
for a good reason.


It's not my problem that you have a constantly broken setup. I have not. 
I use IPv6 for years now at home and in my company and all our internal 
traffic goes over IPv6 and I have no reasons for workarounds.


When I had IPv6 trouble then I contacted the ISP and they fixed it which 
in the end resulted in better monitoring on their side and less trouble.



http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.de/110207


Also this is a typical setup error. If someone accesses "localhost", then 
the tool also must listen on localhost which nowadays means IPv4 and IPv6 
otherwise the address must be 127.0.0.1 which is the IPv4 address for 
localhost.



Sorry - NO - I have a perfectly working ipv6 setup with German Telekom
at home. Even there i need workarounds with josm not falling back
to ipv4 with the tracer plugin.


Then contact the tracer author and tell him to fix his software and not 
to try to access illegal address. Either the tracer plugin must use 
127.0.0.1 only or the tracer tool itself must listen also on ::1.



EVERY single connection needs the fallback logic for itself without
cached prior knowledge of the environment.


No. It does not need this. No software does this for IPv4. Why should we 
do this for IPv6? To make IPv4/IPv6 transition smoother some people 
thought that IPv6 errors should be silently ignored. And what's the result 
- people like you assume that having errors is ok. IT IS NOT OK.



With mobility my ipv4 only connection can change to dualstack to dslight
to a pure ipv6 with 6to4 NAT back to ipv4. If my services are reachable
Dualstack there should be service everywhere. With JOSM the first
change in network environment needs an application restart.


As told multiple times this has technical reasons. Java does not allow to 
switch the handling of IPv6 after I did a single network access. I would 
be happy to have it like for all other tools which follow the OS 
preference, but that's not possible ATM. If you can't live with it, 
disable it. I don't rewrite the whole Java network stack only to satisfy 
your need for perfection.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Florian Lohoff]

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 and you actively blame ipv6 for it.
> 
> 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 sequentially to the resolved
> addresses [4, 5].
> 
> On GitHub I could only find two Java demo projects on the
> java.net.Socket level [6, 7].

Its not about Happy Eyeballs as the real and only solution. Best Common
Practice is whenever you isse a connection and you get  and A
records you try  first and if they fail you fall back to A records
e.g. IPv6 first. This is the fundamental principle of IPv6 introduction
and transition. You NEED people to first try v6 as you want the traffic
to transition to the new protocol. IPv4 is DEAD - No RIR has v4 adresses
anymore so there will be no new Companys with v4 connectivity. Get
over it.

Currently josm tries to be clever and either does v6 or v4 and tries
to detect whether the host is v6 enabled. This is broken by design.
You cant detect whether you will be able to issue v6 connections
until you try. There are v6 blackholes in the internet, there is
intermittet connectivity, there are ULA prefixes which is just an v6
island whathever. Its the INTERNET - Everything is built on a "best
effort" base. It may work - it may also not. IPv6 put the responsibility
for the user experience in the hands of application writers by making
strong recommendations on how to write your applications. If it fails
because the application is broken people turn off ipv6 and will never 
ever turn it back on because of bad reputation. This will hurt
IPv6 adoption and in the end will hurt us all. 


I had all sorts of tricks in my josm startup scripts in the past years to 
tell josm to ignore v6 - to always enable ipv6 etc. First versions of
josm even thought they would be ipv6 enabled if there were a ::1 on
the lo interface. So the josm startup script included a

"ifdown lo; josm &; sleep 30; ifup lo"

That got fixed - now i have the issue that i need to restart josm when i
move to a different network. Need to run tcpproxy in the background
to let josm connect to the tracer server because it does not do a ipv4 
fallback etc..

There are even more broken assumptions in josm. I live in the rural
outback and i have 348kbit/s - Sometimes on josm startup it fails to
fetch the motd or mappaint styles or whetever it tries to do on startup.
Some requests on startup timeout because my line is congested. This
causes josm to refuse to do ANY network interaction afterwards. You cant
download data etc etc. Sometimes i need to start josm 3-4 times until it
actually is willing to play with me. This never happens on a VDSL
50MBit/s connection etc.

I really ask myself how the HOT people work around those issues. Network
connectivity isnt even perfect in Germany, and is most likely even more
flaky in HOT areas. Is josm actually usable without internet
connectivity - editing offline files?

Flo
-- 
Florian Lohoff f...@zz.de
  We need to self-defend - GnuPG/PGP enable your email today!


signature.asc
Description: Digital signature
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Philip Homburg]

> 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 has to work. Yes - we currently have a chance to try again
> with IPv4 and JOSM doesn't use that chance. Well, JOSM doesn't do
> many other things as well.
> 
> But telling me that it's JOSM's fault that providers are incapable
> to do their work properly is nonsense.

As an IPv6 hacker and JOSM user (I don't know about the internals of JOSM):
- If a network has a permanent problem to reach a particular destination, 
  then that's network problem not the application's. In IPv6 land, there is
  the unfortunate Cogent/Hurricane Electric issue. The only option is to
  connect to both. However, transient errors may still occur.
- 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 wide.
- All applications should loop over all addresses returned by getaddrinfo.
  There is simply no excuse not to. If java makes it impossible to iterate
  over all addresses that it is java that is horribly broken.

Just my few cents.


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Layer specific history

[Holger Mappt]

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 action goes into the geo image layer history 
because
that's where the images are.  But an "undo" would not undo the image-GPX 
correlation but the last data layer action because the data layer is 
active.  This might be confusing.


How about a combination of 1) and 2): The history is a linear list of 
actions.  Each action is associated with a layer.  All actions that 
belong to a layer form a virtual history stack.  Each action in the 
history list is either active or undone.  If an action is undone the 
according undone flag is set.  The default is to show/use the linear 
history like it is done now.  With a toggle button it can be switched to 
the (virtual) history of the current layer.  Only the actions of the 
active layer are considered now (history stack display and undo/redo). 
The border between active and undone actions is based on the undone 
flag.  Back to the full linear history: Undone actions that are in the 
active section and active actions in the undone section are grayed out 
to indicate that undo/redo will do nothing with such an action.  Grayed 
out actions are not skipped during undo/redo to keep the history linear. 
 If a grayed out undone action is undone with the linear history the 
color changes back to normal if there is no earlier undone action of the 
same layer because it can be redone now.  Same for the redo direction. 
Actions can be color coded to visualize the layer they belong to.  Each 
layer gets a unique color assigned.  Actions from different layers could 
be displayed like commits in branches are displayed in revision control 
system GUIs.  That will help to understand why grayed out actions cannot 
be undone/redone.


Many ifs and whens, but I think it could work.

Holger


On 2015-12-30 at 19:05 +0100 Vincent Privat wrote:

I think 2) is the best solution. It remains simple for most users who
work on a single modifiable layer at a time, but provides a nice
flexibility for those who work on several layers.
3) is too complex. The less dialogs we have the best it is.


2015-12-29 17:16 GMT+01:00 Holger Mappt:
What is the recommended way to add a command history with undo/redo
functionality to a layer that is not an OSM data layer?  In this
case the GeoImageLayer.

I can imagine three options:
1) One linear history stack for all actions with one interface.
This is what is usually done in other software.  The interface is
the undo/redo in the edit menu and the main toolbar and the command
stack toggle dialog.

2) One history stack per layer with one interface.  Similar to 1),
but undo/redo applies only to the active layer.  This decouples the
actions done in different layers.  It requires that actions done in
one layer do not depend on actions in another layer.  "Layer" can
either be a single layer or one layer type.

To be useful the history needs a concept of "connected actions" and
the possibility to undo unconnected actions independently.  Example:
The key "opening_hours" is added to a POI node, then the key "name"
of an other PI node is changed.  To undo the opening_hours the name
change has to undone too with the current implementation.  But the
two POI nodes are not connected, it should be possible to undo
either change.


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev