[josm-dev] JOSM Applet

[Dirk Stöcker]

On Thu, 3 Mar 2011, Frederik Ramm wrote:

>> >  Was the preference storing feature on the OSM server unsuitable, and if
>> >  so, why? Maybe the OSM server can be amended so that the JOSM applet
>> >  could store its data there rather than on the JOSM server.
>>
>>  I'm not aware the OSM server has a feature to store JOSM preferences. Has
>>  it?
>
> It has a general key-value storing mechanism that uses the normal API (it's 
> not Java-specific stuff), so if you can access the OSM API, you can also 
> store and access preferences, no matter where your applet was loaded from. It 
> is little used so it is well possible that it doesn't have all the 
> functionality required for something like JOSM.
>
> Here's the docs: http://wiki.openstreetmap.org/wiki/API_v0.6#Preferences

The Applet uses a GET/POST method to store XML preferences. I don't know 
who added this (Imi?), but I got it working again. I don't plan to change 
that again without good reason.

>>  Why? Is there a reason to have more trust in the OSM-server
>>  infrastructure?
>
> Personally I don't view the FOSSGIS servers (one of which is currently the 
> "JOSM server") as a production environment on par with the OSM servers. The 
> OSM servers are physically accessible to a skilled admin team; if something 
> breaks, they can easily migrate services to another machine, or get access to 
> the building and fix it. The OSM servers are also the property of OSMF. In 
> contrast, the FOSSGIS servers are loaned to us based on a sponsorship 
> agreement which is not guaranteed to last forever, and if the hardware breaks 
> we're dependent on the provider's staff to fix things. In addition to the

Well, actually I prefer the hosted server method. It is much more flexible 
and the hosting provider has people caring for the hardware. I manage 
several servers and until now I had more problems with own hardware than 
with hosting providers.

In case we really loose the hardware completely I will find a fast 
solution to replace it (at least temporary).

If you have a look at the backup files from josm, you can see, that they 
are designed to allow reinstallation on a new system without a lot of 
effort. The last time I did so (you do remeber I needed to move JOSM 
server twice?) it worked smoothly and since then I improved the 
description file.

> insecurity on the hardware side, I am also concerned about the software side 
> because I think that nobody except you actually knows what is going on on the 
> "JOSM server", and if you should lose interest, be run over by a bus, or just 
> are too annoyed by my constant nagging, then he have a server on which 
> everyone has come to depend but which cannot be maintained properly by 
> anyone.

I think Sebastian knows how to operate the JOSM servers. He may not know 
the finer details necessary for bug-fixing and improvements, but this is 
not necessary for administration. And if necessary he or somebody else 
surely is able learn the missing parts fast. The situation is much better 
than at the time when I took over the server and at that time the user 
interface was much simpler!

Additionally you can have a look yourself too if you feel it is necessary.

Anyway I doubt the situation is much different for OSM servers. If the 
central admin fails you will have trouble there as well.

And BTW: A bit nagging is nothing compared to other stuff I have to deal 
with from time to time.

> Ideally, I would want the "JOSM server" to be the location where you download 
> JOSM, and maybe where tickets are entered, and nothing more. Ideally, I would 
> want us to be able to, at any time, throw away our trac and decide we use 
> another system, or OSM's trac. I also want us to be able to move JOSM hosting 
> to somewhere else, or throw away SVN, or migrate to MediaWiki for the help 
> pages, if at any time it seems reasonable to do so.
>
> Every additional kind of interaction of the software with the "JOSM server", 
> every extra bit of Python magic takes us further away from such resilience. I 
> would like the "JOSM ecosystem" to work even if the "JOSM server" breaks.

Well, you want to turn back time into the time of Web 1.0. Time changed 
and today people expect more comfort. Most of the additional features the 
server provides are former user demands:

* plugin management
* installation file creating
* version checks and download management
* WMS/TMS source handling
* External presets
* External styles
* online help
* online help translation
* translatable MOTD
* Webstart, download and applet version

I also started with the internet in the time, when the Web was not even 
1.0 and I understand your feelings when I see to much services getting 
overloaded with online-functionality.

But I also see the need and comfort of online features. It is required to 
find a balance between online features and the old style, but turning back 
the wheel of time is not possible as well.

I think the development and acceptance of JOSM in the last years proves 
that my current concept is right.

>>  Please note that an Java applet is an 100% pure online component. It must
>>  be based on one server or the other.
>
> If we can get it to work properly then I'm sure it can be hosted on osm.org 
> and be added to the "Edit" drop-down.

Perfectly fine. But it must work on josm.openstreetmap.org, as this is the 
place, where JOSM developers have influence. If the OSM-servers provide it 
as well we can help them, but development will be based on our sphere of 
influence.

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