Answers should take the form of feature requests/modifications that are either obviously beyond the scope of v1 and or have been status-declined or status-deferred
They will be indexed here in the Q.
7 Answers
Move the id value into the query string
In that the id is vectorized, it is designed to represent multiple values.
Currently the id field is a component of the url. This severely constrains the number of records that can be retrieved far below the stated maximum of the max pagesize which is 100.
Another, more serious, implication of this limitation is that, with id in the url, the limit is arbitrary and undefined, which is never a good thing, requiring trial and error to find the max url length in respect to the variable length id, or make many single id requests increasing load on the server.
If the id were a query string component, it is quite possible to issue a request for 100 items even with large id. Currently, using short id values, the server starts issuing errors at ~30 items.
What I would like to see:
/path?id=123;456;789
Which would obviate the necessary hack described here
Comments
User Authentication
This is an obvious one (and a stated goal for V2, I think).
The basics would be for some way to authenticate a user against his StackOverflow/etc user. Also, a way to access the "linked accounts" information would be great (so authenticating a StackOverflow user will automatically give the application knowledge of his other accounts which are linked to the same user).
That last part might be problematic, so some way of letting the user disallow sharing the linked info/informing the user is important.
1 Comment
Charles Stewart
Do you have a source for the "stated goal for V2" bit? The "I think" bit suggests not, I guess...
Users's Favorite Tags
Having access to a given user's favorite tags would make it much easier to provide a customized user experience where tailoring to the user's preferences could be automatic.
2 Comments
Sky Sanders
this one should be an easy expose and does not seem to pose any privacy issues. too bad it didn't get suggested a few weeks ago.
lfoust
this was suggested a while back on the old stack apps beta site and was marked as postponed until v2.
The ability to post questions/answers.
This is important for the question-answering robot I'll be making.
3 Comments
Maxim Zaslavsky
Was I right in interpreting the second sentence of your answer as a joke? :)
Nathan Osman
@Maxim: Actually, no... I really am going to write an app that searches the question for key words and then uses an algorithm to look up possible answers on search engines and posts them :)
Igor Zevaka
Nooo.... How are people supposed to get lots of rep by answering the same noob question every week about their language of choice :)
Ability to get at the questions user voted on
At this stage I see no way to get what questions and answers user has voted on. It would be good to have this ability for future releases of my app.
Seeing other user's votes is a pretty bad idea as they are meant to be private.
6 Comments
Sky Sanders
this information is intentionally omitted. the potential for abuse is far too high. Favorites are the best you gonna get.
Nathan Osman
@code: But in v2.0, this could probably be allowed via OAuth or some other authentication method.
Sky Sanders
@geo - it's not a matter of determining/controlling who can see it, it is a matter of privacy. it will never happen.
Nathan Osman
@code: Well... you can see your own votes. Why can't an app authenticating on your behalf see them too?
Sky Sanders
@geo - ok, i was not looking at it from that perspective. in the context of igor's app, i can see a use case. but spying on another user's up/downs will never happen, which is what i should have said clearly.
|