source: subversion/sites/other/tilesAtHome_tahngo/TODO

Last change on this file was 20743, checked in by ser, 10 years ago
  • a slightly revised list.
File size: 2.4 KB
1t@h server
4 - Investigate switch to Postgresql as this one runs on the box anyway
5 - Minimize "* Server load too high, unlikely we can upload after rendering, waiting 30s.."
6 - "Render this tile" button on the tile detail page
7 - Check MYSQL "FOR UPDATE locks". Small race conditions could enable handing out the same job twice?! Seems fine though.
8 - Think about notifying users when their clients fail too often, more verbose collection of client's efficiency and quality of renders.
9 - Enable client to hand back requests as "oldData" (ie API data older than tileset on server) which would delete the request.
10 - Save the client_uuid in the request database with finished requests
11 - Check the "LayerCapabilities" of the client and only send appropriate requests.
12 - Discard incomplete tileset uploads (mail user?). Check for obvious failures? (better on client side)
13 - Make lowzoom stitching run in a good way (cron). Implement blacklisted areas for people wanting to upload their own lowzoom.
14 - Improve "feedback" API. Make sure we reset only tilesets assigned to that one client. Make sure, we record the client_uuid in the feedback case.
15 - Examine the password situation. why are non-character passwords failing? It works fine on the server side of things. Put on hold for now.
16 - introduce "minimal complexity" parameter requested by the client (e.g i have plenty of memory and i do not want to spend the time for rendering non-complex tiles)
17 - more intelligence within the process of distributing jobs to clients.
19t@h client (will not be implemented by spaetz)
21 - assemble tilesets on the clientside already, don't upload zip files
22 - generally go through the code and remove superfluous code (e.g. non-tileset uploads)
23 - Send the current client version as data (or other numeric) string that we can compare against. We don't want to maintain a list of city names in the server.
24 - check last-modified age of tileset, compare with API age and skip request if the tileset on the server is younger already
25 - return a request if the tileset complexity is higher than what the client is willing to handle
26 - Fork the rendering in 2 threads, have one already downloading the next task, while the first is still rendering the tiles.
27   (downloading can take quite a while, but doesn't consume lots of resources - at least on the client side, so we could speed up rendering by doing this already)
Note: See TracBrowser for help on using the repository browser.