[Tilesathome] API 0.6 migration

[a_a at gmx.de]

Matthias Julius wrote:
> a_a at gmx.de writes:
> 
>> Hi all,
>>
>> as the API 0.6 is on the air now I'd like to bring up T at H migration to 0.6:
>> As far as I can see T at H with 0.5 is still working, but has some 
>> disadvantages:
>> - the only leftover 0.5 data source is XAPI with
>>    http://www.informationfreeway.org/api/0.5/*[bbox=<BBOX>]
>> - the data is outdated (i.e. no new 0.6 changes get there)
>>
>> The migration would maily be just to set "OSMVersion" to "0.6" in 
>> "general.conf": I've already tried this and it worked properly. Running 
>> the client in 0.6 version there's only a warning from area-center 
>> "Expected version 0.5 but received 0.6.", but that can be ignored 
>> momentarily.
>> The disadvantage of a migration to 0.6 _now_ would be in my point of 
>> view that at the moment the main API server would be the only 
>> (realtively slow) data source, because as far as I can see XAPI and ROMA 
>> are _not_ migrated to 0.6 yet (mainly because the minute planet diffs 
>> are not yet available and bretth is sleeping right now).
>> So I'd opt for staying at 0.5 for at least another day.
> 
> Do ROMA and TRAPI need to be migrated to API 0.6 in order to be able
> to read 0.6 diffs?
Well, they could theoretically stay in 0.5 mode...


 > If so T at H can not use them anyway after the main
> API switch because they would not be able to update themselves.
I don't understand that. Please explain.


> Otherwise, OSMVersion is substituted into the download URLs for a
> placeholder (%v I believe). 
That I was talking about above: Change "OSMVersion" to "0.6" in 
"general.conf".


 > This placeholder could just be replaced by
> the API version in the config file to make the client download from
> different API versions from different servers.
So you are thinking about a dual-API-version strategy in the client?


Best regards

Alfons