Get your own customer support community

About me

Website
http://www.opensourcec.org/...

Recent activity

Subscribe to this feed
  • problem

    Bill Bosacker replied on November 12, 2009 22:25 to the problem "API issues" in Daylife:

    Bill Bosacker
    Ok, I figured out what I'm seeing now. If a start_time is set and there are no new articles since that time, the API is returning the following null <article> record:

    <response><message type="str">Success</message><code type="int4">2001</code><payload><article /></payload></response>

    Is this correct? I was expecting no <payload> at all, or a null <payload>.
    Do you think this solves the problem? Mark it as solved
  • question

    Bill Bosacker replied on November 11, 2009 09:54 to the question "Response Information" in Daylife:

    Bill Bosacker
    P.P.S Sorry for the multiple responses, but I wanted to let you know about the full WCF client that I have written for your API and that we plan to release as open source. We had been talking with John Donovan through email about it, but we haven't heard anything from John in over a month.

    The client is fully functional, but the responses are not 100% hard typed as we need to have all of the response schemas completely documented to accomplish that. In the mean time, I have added [XmlAnyElement] attributes to each response level object, which makes the responses mostly hard typed and partially soft typed.

    If you would like a compiled beta copy of the current library, let me know. We wiill be releasing it under a non-compete open source agreement, once I feel comfortable that it will require very little time to support.
    Do you think this answers the question? Mark it as answered
  • problem

    Bill Bosacker replied on November 10, 2009 22:21 to the problem "API issues" in Daylife:

    Bill Bosacker
    Problem #1 appears to have been fixed now. I just did a test and it is now working. I may be seeing another issue now, but I need to look into it further.
    Do you think this solves the problem? Mark it as solved
  • question

    Bill Bosacker replied on November 10, 2009 19:24 to the question "Response Information" in Daylife:

    Bill Bosacker
    P.S. We need to know which elements may return nulls and which may return empty strings.
    Do you think this answers the question? Mark it as answered
  • question

    Bill Bosacker replied on November 10, 2009 19:06 to the question "Response Information" in Daylife:

    Bill Bosacker
    Hi Vineet,

    For now, we can get by with the resultset schema for the 'topic_getRelatedArticles' call as we are polling your system and storing the results in our news system. From what I've been able to see, it appears that each call has its own resultset schema. For example, the schema for the 'response/payload/article' element in the 'topic_getRelatedArticles' call is slightly different (different sub-elements) from that of other calls. If I ask for images, there is an <article> sub-element in the <image> element ('response/payload/article/image/article') that is different as well. I can understand this as it would cause a recursion problem, but the schema definition is a must have. Without it, it is impossible to parse a heirarcal XML document with multiple levels.

    Thanks,
    Bill</image></article>
    Do you think this answers the question? Mark it as answered
  • problem

    Bill Bosacker replied on November 10, 2009 18:53 to the problem "API issues" in Daylife:

    Bill Bosacker
    Hi Vineet,

    Problem #1:
    I know that that is how it is supposed to work, the problem is that it does not work that way, as I stated in my first message. For example:

    Lets say that I set a time block for the resultset for which I know that there are n results. If limit is less than or equal to n, I need to make multiple call requests, each with a sliding offset (i.e. offset=limit*iteration). The problem is that no matter what the iteration is, and thus the offset, your system will never return less that limit results.

    I used the differing limits of 10 and 100 to prove the point. With a 100 limit I could see that there were only 16 results and thus I don't need to iterate further. However, with a 10 limit I get 10 results on the first iteration (line a in you example) and need to make a second iteration. On the second iteration (line b in your example) I again get 10 results instead of the 6 that I should, which is the problem. I can iterate forever and your system will always return 10 results.

    Problem #2:
    I was really hoping that this was not the case as it is going to cause a weird stair stepping as we poll your system for updates. Instead of receiving results in a chronological order, we'll be receiving them in a sawtooth staircase pattern. If there is any kind of failure, we will be left with a timespan hole that needs to be filled. The coding to detect this hole is going to be ridiculous and will most likely result in multiple duplicate resultset calls to ensure that there isn't a hole.

    With a start date, no end date, and an ascending time line, we would never have a hole. All successive calls could be made with a start date of the latest received timestamp_epoch + 1.

    Problem #3:
    As I stated in the first message, there is a work-around for the mis-ordering of elements, so it does not need to be addressed. However, there is no work-around for the duplicate names violation in the request. For example, having 2 or more 'topic_id' name parameters in the request (i.e. "?topic_id=1&topic_id=2&topic_id=3&...") is a WC3 invalid HTTP request violation (not a Microsoft thing). That is what needs to be addressed.

    Thanks,
    Bill
    Do you think this solves the problem? Mark it as solved
  • question

    Bill Bosacker asked a question in Daylife on November 10, 2009 04:01:

    Bill Bosacker
    Response Information
    There is quite a bit of information on creating requests, but I don't see any information about the data returned in the response. I've been able to handle all of the response elements, but I have absolutely no idea what some of them are, or what they mean. Is there a document that defines exactly what data is returned in each element?
  • problem

    William Bosacker reported a problem in Daylife on November 06, 2009 15:14:

    William Bosacker
    API issues
    I've written a WCF client for all of the non-batch calls, but there are some issues that we have run into that are preventing us from using the API. We had been discussing them with John Donovan through email, but we haven't received replies for some questions, and the others have taken over 2 weeks to get a reply.

    Problem #1 (unable to see if its been fixed due to Problem #2):
    If there are fewer total results than the limit, then we will only get those results. However, if the total number of results exceeds the limit (n), then no matter what the offset is set to, we always get back n (limit) results. I know it sounds weird, but that is what we’ve observed. Here is an example:

    If we set the limit to 100 and there are only 16 results total, we get those 16 results. If we set the limit to 10, we will always get 10 results back no matter what the offset if set too. Even if the offset is set to 10,000, we still get back 10 results. I haven’t tried it since I sent you the reply on 10/2/2009, but I can try it again if you like. This can be seen in the Daylife API Tester as well, which is where I first observed the issue.

    Problem #2:
    When setting the sort property to "date", the response is returning items in descending order, whereas the documentation states that it should be in ascending order. I'm hoping that this is just an error in the current server code as descending order means that we'll be receiving a huge number of duplicate responses.

    Problem #3:
    The API is not fully compliant with the WC3 specification while Microsoft wrote WCF to be strictly compliant to the WC3 specification.. There is also one compliance issue in the WC3 specification that contradicts a previous WC3 specification, and Microsoft unfortunately followed the rule that is in contradiction. The good thing is that I was able to completely work around that issue by using the XmlSerializer. That WC3 contradiction issue is related to the ordering of elements where the main text states that order cannot be guaranteed, while later text states that order must be specific. As you know, the ordering of response elements appears to be random, thus the default serializer does not work.

    The issue that I am not able to work around is due to a violation in the QueryString request. The WC3 specification states that the name of all name-value pairs must be unique, and WCF does not allow this to be overridden. However, it can easily be fixed if the API is corrected to be WC3 compliant that does something like the following pseudo-code:

    Good: topic_id=UrlEncode(UrlEncode(“topic1”)+“,”+UrlEncode(“topic2”))
    Bad: topic_id=UrlEncode(“topic1”)&topic_id=UrlEncode(“topic2”)

    Thanks,
    Bill Bosacker