We should get sitemaps quickly and keep up with their changes. This is especially true of our own.
A series of github pull requests (github 
, github and github ) provides better server-side support. Seeing the way the sitemap is served changed so that the client can cache it. The server overhead of requesting the sitemap is reduced by keeping the sitemap up to date as the site is edited.
There remains a client limitation that the sitemap is not updated once it gets loaded. For the origin this means it will not include the results of any page creations and edits made. For other sites they are loaded when you first add the site into the neighbourhood.
The current client does not currently have code to reflect any site's sitemap into the GUI. This is probably one of the next sitemap related areas for enhancement.
How many sitemaps are too many? If we get them fast will we want even more? Hundreds? Thousands?
Maybe we need to remove the page synopsis from the sitemap, and do search a different way?!
We could prune the neighborhood to only those sitemaps called for by the current lineup. This would mean that the lineup url will accurately represent a neighborhood. See URLs not Idempotent
.
Sitemaps when loaded become part of the neighborhood. But, does it have to be that way? One place where we would want to load a set of sitemaps, but not extended the neighborhood, is in a client-side construction of a conversation view.