Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
@george, 53346 is a question, I can only assume that you are looking for answer your answer - try 53466. soapi.info/code/js/stable/soapi-explore-beta.htm is a good tool for building queries and examining the expected results.
@smark - no worries dude. Now I see. I am going to delete my FRIST! that makes me look like a complete idiot now. thanks for the heads up, we can delete these comments if you like... unless you want to look like you are talking to your self ;p
@robert - if you look at generated api consumer code as a core library and the bulk of your code and then wrap your wrapper with purty code the story becomes a bit more compelling. Kevin ++.
++ for 'package it howz you likes it' @ColinD - consistent api calls, or symmetry as kevin says, make consumption less complex in my experience. which is a good thing.
And I typically chain calls that would otherwise be suited to be run synchronously. e.g. make the next call from within the success function. With a little imagination and a flag or two this can serve such a purpose. And as far as a queue goes, I have an implementation somewhere in my qunit code. I will try to dig it up.
Aside from the obvious dark pit of hades into which I would be thrown if I were able to implement a blocking call in JS, how to implement a blocking call in a jsonp wrapper is not immediately apparent to me. The api calls are made via jsonp, injected script tags, not XMLHttpRequest. Do you have any ideas? I have implemented a viable blocking call in the silverlight version, but then I have threads and am able to force the call to be made on a thread other than the UI thread. No such animal in regards to browsers (workers in chrome) in general distribution any time in the near future.
So, silverlight is sending accept-encoding = identity which equates to no encoding and apparently the servers are honoring it. Which is a good thing. If it stops, a lot of (valuable) hours of development time for an unknown number of devoted SO aficionado will be lost.
If you force gzip you will break Silverlight 3 (and possibly 4) clients. Unless there is a 'strict in what you issue, relaxed in what you accept' feature in the SL stack that I haven't tested. When I get a moment I will build a server that only pushes gzip and see how the SL stack handles it.
I am not sure you are picking up what I am putting down: Silverlight ClientHttp stack does not support gzip. That is the code we are talking about here. But Soapi is here: [email protected]/bitpusher/soapi - I am pushing on documentation and last minute adjustments but I generally only push compilable code. Open the vs9 solution - I haven't reviewed the vs10 solution in the last few hours and since I am linking files I promise it is broken. Soapi.SL.Tests is what you are looking for.
@george - last time I checked it did not support javascript xml comments. I will take another look. I certainly do not look forward to managing this myself. I have other things I would like to do. Thanks for the heads up.
@farseeker - the method names are not the prettiest, but as I intend all of the Soapi libraries to serve as solid core foundations upon which higher level libraries can be built I felt it would be best to generate all of the identifiers directly from the api specs. Once I have the core libraries up I will post examples of extending Soapi with lazy loaded object graphs. say, start with a Users, dot Questions will load questions if empty (Users.Questions.load/refresh are explicit directives) and so on throughout the object graph enabling fluent dot navigation across the entire api.
