Skip to main content
replaced http://meta.stackexchange.com/ with https://meta.stackexchange.com/
Source Link

For the same reasons I lay out herethe same reasons I lay out here it can't really appear here.

It has none of the aggregation code in place for reputation, "posts", etc. If it did then we'd have to keep it in sync 2 places (things would break everywhere otherwise since it's serialization pain). In the user profile we one-off fetch it in the cache load since that fetches from a similar cache as the site switcher does for rep. However, since the site switcher is included on every page we can't have any delay.

For reputation specifically, we would have to aggregate every reputation change, merge, deletion, etc., clear several caches when that happens, and also mix concepts of what the schema means (Area 51 isn't Q&A, some things don't translate). It adds complexity to the dropdown as well since the links aren't to the same place or format, but that's a different can of worms.

Adding it adds pain, decreases performance, and means a whole set of APIs to keep in sync. Given that we don't know what will happen with Area 51 a year from now, this implementation is not something we want to spend a great deal of time (and continued maintenance) on.

For the same reasons I lay out here it can't really appear here.

It has none of the aggregation code in place for reputation, "posts", etc. If it did then we'd have to keep it in sync 2 places (things would break everywhere otherwise since it's serialization pain). In the user profile we one-off fetch it in the cache load since that fetches from a similar cache as the site switcher does for rep. However, since the site switcher is included on every page we can't have any delay.

For reputation specifically, we would have to aggregate every reputation change, merge, deletion, etc., clear several caches when that happens, and also mix concepts of what the schema means (Area 51 isn't Q&A, some things don't translate). It adds complexity to the dropdown as well since the links aren't to the same place or format, but that's a different can of worms.

Adding it adds pain, decreases performance, and means a whole set of APIs to keep in sync. Given that we don't know what will happen with Area 51 a year from now, this implementation is not something we want to spend a great deal of time (and continued maintenance) on.

For the same reasons I lay out here it can't really appear here.

It has none of the aggregation code in place for reputation, "posts", etc. If it did then we'd have to keep it in sync 2 places (things would break everywhere otherwise since it's serialization pain). In the user profile we one-off fetch it in the cache load since that fetches from a similar cache as the site switcher does for rep. However, since the site switcher is included on every page we can't have any delay.

For reputation specifically, we would have to aggregate every reputation change, merge, deletion, etc., clear several caches when that happens, and also mix concepts of what the schema means (Area 51 isn't Q&A, some things don't translate). It adds complexity to the dropdown as well since the links aren't to the same place or format, but that's a different can of worms.

Adding it adds pain, decreases performance, and means a whole set of APIs to keep in sync. Given that we don't know what will happen with Area 51 a year from now, this implementation is not something we want to spend a great deal of time (and continued maintenance) on.

"repution" -> "reputation" (also changed "rep" -> "reputation" because <6 character proposed edits are not allowed...)
Source Link

For the same reasons I lay out here it can't really appear here.

It has none of the aggregation code in place for reputionreputation, "posts", etc. If it did then we'd have to keep it in sync 2 places (things would break everywhere otherwise since it's serialization pain). In the user profile we one-off fetch it in the cache load since that fetches from a similar cache as the site switcher does for rep. However, since the site switcher is included on every page we can't have any delay.

For reputation specifically, we would have to aggregate every repreputation change, merge, deletion, etc., clear several caches when that happens, and also mix concepts of what the schema means (Area 51 isn't Q&A, some things don't translate). It adds complexity to the dropdown as well since the links aren't to the same place or format, but that's a different can of worms.

Adding it adds pain, decreases performance, and means a whole set of APIs to keep in sync. Given that we don't know what will happen with Area 51 a year from now, this implementation is not something we want to spend a great deal of time (and continued maintenance) on.

For the same reasons I lay out here it can't really appear here.

It has none of the aggregation code in place for repution, "posts", etc. If it did then we'd have to keep it in sync 2 places (things would break everywhere otherwise since it's serialization pain). In the user profile we one-off fetch it in the cache load since that fetches from a similar cache as the site switcher does for rep. However, since the site switcher is included on every page we can't have any delay.

For reputation specifically, we would have to aggregate every rep change, merge, deletion, etc., clear several caches when that happens, and also mix concepts of what the schema means (Area 51 isn't Q&A, some things don't translate). It adds complexity to the dropdown as well since the links aren't to the same place or format, but that's a different can of worms.

Adding it adds pain, decreases performance, and means a whole set of APIs to keep in sync. Given that we don't know what will happen with Area 51 a year from now, this implementation is not something we want to spend a great deal of time (and continued maintenance) on.

For the same reasons I lay out here it can't really appear here.

It has none of the aggregation code in place for reputation, "posts", etc. If it did then we'd have to keep it in sync 2 places (things would break everywhere otherwise since it's serialization pain). In the user profile we one-off fetch it in the cache load since that fetches from a similar cache as the site switcher does for rep. However, since the site switcher is included on every page we can't have any delay.

For reputation specifically, we would have to aggregate every reputation change, merge, deletion, etc., clear several caches when that happens, and also mix concepts of what the schema means (Area 51 isn't Q&A, some things don't translate). It adds complexity to the dropdown as well since the links aren't to the same place or format, but that's a different can of worms.

Adding it adds pain, decreases performance, and means a whole set of APIs to keep in sync. Given that we don't know what will happen with Area 51 a year from now, this implementation is not something we want to spend a great deal of time (and continued maintenance) on.

Migration of MSO links to MSE links
Source Link

For the same reasons I lay out herethe same reasons I lay out here it can't really appear here.

It has none of the aggregation code in place for repution, "posts", etc. If it did then we'd have to keep it in sync 2 places (things would break everywhere otherwise since it's serialization pain). In the user profile we one-off fetch it in the cache load since that fetches from a similar cache as the site switcher does for rep. However, since the site switcher is included on every page we can't have any delay.

For reputation specifically, we would have to aggregate every rep change, merge, deletion, etc., clear several caches when that happens, and also mix concepts of what the schema means (Area 51 isn't Q&A, some things don't translate). It adds complexity to the dropdown as well since the links aren't to the same place or format, but that's a different can of worms.

Adding it adds pain, decreases performance, and means a whole set of APIs to keep in sync. Given that we don't know what will happen with Area 51 a year from now, this implementation is not something we want to spend a great deal of time (and continued maintenance) on.

For the same reasons I lay out here it can't really appear here.

It has none of the aggregation code in place for repution, "posts", etc. If it did then we'd have to keep it in sync 2 places (things would break everywhere otherwise since it's serialization pain). In the user profile we one-off fetch it in the cache load since that fetches from a similar cache as the site switcher does for rep. However, since the site switcher is included on every page we can't have any delay.

For reputation specifically, we would have to aggregate every rep change, merge, deletion, etc., clear several caches when that happens, and also mix concepts of what the schema means (Area 51 isn't Q&A, some things don't translate). It adds complexity to the dropdown as well since the links aren't to the same place or format, but that's a different can of worms.

Adding it adds pain, decreases performance, and means a whole set of APIs to keep in sync. Given that we don't know what will happen with Area 51 a year from now, this implementation is not something we want to spend a great deal of time (and continued maintenance) on.

For the same reasons I lay out here it can't really appear here.

It has none of the aggregation code in place for repution, "posts", etc. If it did then we'd have to keep it in sync 2 places (things would break everywhere otherwise since it's serialization pain). In the user profile we one-off fetch it in the cache load since that fetches from a similar cache as the site switcher does for rep. However, since the site switcher is included on every page we can't have any delay.

For reputation specifically, we would have to aggregate every rep change, merge, deletion, etc., clear several caches when that happens, and also mix concepts of what the schema means (Area 51 isn't Q&A, some things don't translate). It adds complexity to the dropdown as well since the links aren't to the same place or format, but that's a different can of worms.

Adding it adds pain, decreases performance, and means a whole set of APIs to keep in sync. Given that we don't know what will happen with Area 51 a year from now, this implementation is not something we want to spend a great deal of time (and continued maintenance) on.

Source Link
Nick Craver Mod
  • 125.5k
  • 25
  • 432
  • 571
Loading