1

This should be the correct behaviour:

name: "Stack Overflow Meta"
name: "Web Apps Meta"
name: "Gaming Meta"
..

For the newcomers Server Fault and Super User, Meta is before the parent site in the name.
..
name: "Meta Server Fault"
name: "Meta Super User"

name parameter is pretty useful and it's the only way for apps to dynamically display sites choices retrieved from Stackauth.

EDIT:
After Jeff's answer, the only name that should be corrected is:

name: "Stack Overflow Meta"

It should be:

name: "Meta Stack Overflow"

EDIT2:
This has been fixed!

Improve this question
15
  • 1
    good catch. This is one reason that I key off of the api_endpoint only. Commented Jul 25, 2010 at 21:00
  • @code at first sight, i thought it was a bug on my new sites ordering :P i'm working on. Uhm, I key off the domain without the first level and protocol. Commented Jul 25, 2010 at 21:04
  • @systempuntoout - you're supposed to key off of the domain and the provided aliases (of which there are none, yet, but eventually...). You're doing it right, basically. Commented Jul 25, 2010 at 21:05
  • @kevin - you are talking about the site_url or the api_endpoint and will they ever diverge, e.g. gaming.stackexchange.com comes out of beta and becomes allyourbase.stackexchange.com while the api remains api.gaming.stackexchange.com ?? The way this is to be handled and what to expect in the alias array are not clear to me. Will alias be the abandoned, or redirected urls? Commented Jul 25, 2010 at 21:10
  • @code - the 'key' on /sites is the site_url. aliases holds all old site_urls, so there's a many->one mapping there. api_endpoint is not anticipated to change, but can. When sites come out of beta, urls to pages on the site will be redirected but the api endpoint will simply go away. Commented Jul 25, 2010 at 21:14
  • ah.. and i key off of site_url and not api_endpoint. Commented Jul 25, 2010 at 21:16
  • 1
    @kev - this is going to make data storage, query and maintenance ummm interesting? I am not sure if I could think of a more painful way to identify resources. I mean really, keys are not meant to be meaningful, the are meant to identify a resource regardless of mutable data like the name human beings call it. So not only did we not get a meaningful key for a site, which could be anything as long as it did not change, to a primary field that WILL change and then the only way to correlate is to rely on an indeterminant number of 'alias'?? really? worst. design. ever. Commented Jul 25, 2010 at 21:28
  • @code poet - uhm, many->one is not hard. Like, really. Hell, you can do it with Dictionary<string, YourSiteObject> and no additional work... Commented Jul 25, 2010 at 21:33
  • @kevin - it is not 1:M or M:1. It is more complicated than that on many levels. You see things from one perspective and refuse to entertain the possibility that when it is you against many, maybe it is you. your workaround, like several in the past that i have just let go, is naive and dismissive and demonstrates either a lack of experience or a misinformed disregard for the concerns that continue to be brought to you by several seasoned voices. some more eloquent and tempered than others but all experienced in the way that only years of getting it right and getting it wrong can make one. Commented Jul 25, 2010 at 23:33
  • @kevin - don't get me wrong; i certainly see no value in getting into a pissing match. but man, it is frustrating when it would take so little effort and cost so little to just do it right. and by right I mean in a way that benefits more people and makes life easier and code simpler. one day, maybe. so no hard feelings, i just need make it clear how counter intuitive and painful some of your decisions are. nobody's perfect. Commented Jul 25, 2010 at 23:37
  • @kevin. i was in rare form, eh? 5 hours of sleep can do wonders for ones attitude. I just occurred to me that the data store for each site must be a distinct silo, i.e. an distinct database instance or equivalent partition and as such needs no site discriminator. this will get me halfway to seeing your position that there are no keys and that they make no sense. I know discussing implementation details is not something you want to do and I understand but come on dude, throw us a bone or two. I know it would help me. Commented Jul 26, 2010 at 5:19
  • @code poet - internally, sites are keyed off the equivalent to site_url. There is some DB overlap between sites (ie many-> sites->DB), though I'm not going to discuss particulars. When I say that the site_url scheme works, I have very hard evidence that it does. Commented Jul 26, 2010 at 5:22
  • @kevin, ok, that is how i have had to design my database implementations, e.g. composite key on every table with a varchar(100) component, and I can almost sleep at night but the imposition of a separate process to maintain those relations really gives me a rash. I am not to promote what should be, in my models, a scalar discriminator in to a lookup structure, that would just be silly. so I guess I just have to be diligent and build contingencies into any app/silo that i wish to participate in aggregation and update my discriminators when you do. Commented Jul 26, 2010 at 5:36
  • @kevin, from you perspective, changing the key takes care of itself via cascaded updates or the equivalent and is determistic - a decision is made and the change occurs during a maintenance period, no harm no foul. But from our perspective, these changes are arbitrary tasking us with being constantly checking to see if something as fundamental as a key has changed and reacting after the fact when any data that we have created/related/stored for a site reaches end of life until we update all the tables, every where. it is this aspect of stackoverflow->API<-consumers that is being disregarded Commented Jul 26, 2010 at 5:42
  • @code - stackapps.com/questions/1226/… details how you use /sites. It works, really. I'd drop it until you can give a concrete counter example (that would be solved by some magic key, of course). Commented Jul 26, 2010 at 6:16

2 Answers 2

Reset to default
4

Note that Meta Stack Overflow is, and has always been, Meta Stack Overflow.

not Stack Overflow Meta.

Thus, these members of the trilogy inherit that naming choice.

Improve this answer
2
  • Jeff, I have seen both in a wide variety of contexts, most commonly as 'stack overflow meta' and most relevant to this conversation, from stackauth "name": "Stack Overflow Meta", might want to look into that. Commented Jul 26, 2010 at 6:30
  • have a look in /sites response stackauth.com/1.0/sites, there's "Stack Overflow Meta" and not "Meta Stack Overflow".See my edit. Commented Jul 26, 2010 at 6:36
0

Infer meta relationships based on the site_url, not name.

The differences in naming scheme are intentional.

Improve this answer
6
  • @Kevin -1 i don't have problem in infer meta relationship and i'm not using name to infer them. Commented Jul 25, 2010 at 21:28
  • @systempuntoout - the name of the Web Apps meta site is "Web Apps Meta" not "Meta Web Apps". Likewise, the SuperUser meta site is "Meta Super User". That's the intentional part. The inferring part is more for future readers, honestly. Commented Jul 25, 2010 at 21:39
  • @systempuntoout - they do because they do. Its like asking why StackOverflow's name ends with Overflow. Its an intentional difference in the naming convention. This is all independent of the API as well. Commented Jul 25, 2010 at 21:45
  • 1
    @Kevin "Its like asking why StackOverflow's name ends with Overflow" is offensive. Commented Jul 25, 2010 at 22:07
  • 2
    @system it's actually Stack Overflow (notice the space) Commented Jul 26, 2010 at 1:02
  • 1
    @jeff - you should have been @ing kevin, system was quoting him. Commented Jul 30, 2010 at 10:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.