Jump to content

steffen.opel

Members
  • Content count

    15
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by steffen.opel


  1. With regards to C# JsonClient, it is simple matter of the programmer neglecting to log the data. Whoever hired that monkey should be fired along with the monkey. ;–)

    Created issue: https://github.com/cityindex/CIAPI.CS/issues/issue/1

    Well, the programmer in charge seems to be well prepared for all things logging at least: I noticed a commit regarding Common.Logging a couple of days ago already – excellent choice for .NET clients :)


  2.  

    Is there a way to get further details of exactly what the requests / response header/body is?

    One tooling agnostic option would be a web debugging proxy for request / response interception and introspection: a common and excellent choice is Fiddler (.NET / freeware), but commercial offerings do exist as well of course, with Charles (Java / shareware) being the top most choice on my evaluation list currently.

    Using Fiddler is pretty straight forward with the following three common scenarios:

     

    @mrdavidlaing – verbose logging options are a very effective debugging and monitoring aid, but granular instrumentation (ideally at runtime) is crucial in this case, i.e. you want to be able to specify verbosity and facility in order to restrict logging output regarding the amount of information desired for the task at hand (otherwise one can easily miss the forest for the trees …) – given other answers it looks like this is taking care of already :)


  3. JsonClient

    CityIndex.JsonClient.IJsonClient

     represents the core of the library and exposes 3 methods (with overloads for brevity)

    • BeginRequest<TDTO>
    • EndRequest<TDTO>
    • Request<TDTO>

    The first two are obviously an async implementation and the last, 

    Request<TDTO>

     (a better name is welcome), presents itself as a sync method but is, internally, a wrapper that calls the async methods.

    I chose this route to elimate logic duplication that would be introduced if I were to leverage the sync methods of WebRequest. I made this mistake in Soapi and have never stopped regretting it.

    BeginRequest<TDTO>/EndRequest<TDTO>

     present a standard .net async pattern in that you call 

    BeginRequest

     with an async callback and the relevant parameters and receive an async result object in the callback.

    EndRequest

     is called with the async result object and the result of the request is returned OR any exception encountered during the execution of the request is rethrown. This functionality could be exposed directly on the async result but following the standard .net async pattern allows for a checkpoint in JsonClient for metrics and/or corelation.

    ...
    client.BeginRequest<FooDTO>(MyCallback, state,params);
    ...     
    void MyCallback(ApiAsyncResult<FooDTO> result)
    {
          try
       {
          FooDTO response = client.EndRequest(result);
          // do something with response.
       }
       catch(Exception ex)
       {
          // something bad happened
       }
    }
    Request<TDTO>

    , as stated, is a simple blocking wrapper for the async implementation.

    ...
    try
    {
       FooDTO response = client.Request<FooDTO>(params);
       // do something with response.
    }
    catch(Exception ex)
    {
       // something bad happened
    }

    Thus concludes the public surface area of the functionality of the JsonClient library.

    While musing about Synchronous vs Asynchronous and the new/alternative Task Parallel Library (TPL)offerings still, I just realized that your BeginRequest()/EndRequest() methods do in fact not fully resemble a standard .net async pattern, in so far there is no IAsyncResult return value available for BeginRequest(), rendering several related usage patterns inapplicable (not the least the TPL’s mentionedTaskFactory.FromAsync wrappers) – is this a deliberate choice?


  4. Apparently you need 50 points to delete your own comment (and 50 points to create a comment) – so the bug might be in that you were able to create a comment without 50 points.

    Arrgh – their defaults and especially their stability aren’t quite there yet, I’m afraid … To add to that impression: I'just failed to add the following comment to your answer to Why does updating a comment disable Markdown syntax?: ‘Unfortunately I can’t up vote there yet: You need a reputation of 1 to Vote up’ – the comment get’s created and confirmed, but just isn’t there anymore after I hit refresh :(


  5. At this stage of the game its probably better for us to remain in “private/invite only” mode.

    However, I’d be interested to learn from the Webservices API proposal story; in proparation for when we are ready to solicit public feedback.

    Thanks for the clarification – that’s what I suspected indeed, just wanted to make sure not to miss out on an opportunity otherwise.


  6. It has already been stated that none is necessarily better, rather depending on the particular use case, i.e. headless vs. UI scenarios, which are both prevalent in web programming environments. Consequently I’d hesitate to favor one over the other for the API as well, expose both query methods and stress use cases by sample within the documentation instead (i.e. UI bound client oriented samples via asynchronous requests and headless server oriented samples via synchronous requests).

    Here are some arguments for retaining asynchronous requests as first class citizens:

    • Asynchronous patterns have well known and justified use cases and should be available for developers who are inclined and capable to master them.
    • As mentioned already, JavaScript and Silverlight only support asynchronous requests by default, and while this change from Silverlight 1.0 has been very controversial, it is currently a fact of life developers are used to deal with (though some workarounds do exist: see Making Silverlight Emulate Synchronous Requests for a short summary in favor of the asynchronous pattern and one workaround still, and Silverlight: Prefer synchronous web service calls for the converse argument including a more elaborate workaround).
    • The .NET Framework 4 features the Task Parallel Library (TPL) with the stated goal thattasks are the preferred API for writing multi-threaded, asynchronous, and parallel code; I currently share the enthusiasm about the simplification of multithreaded scenarios and resulting productivity gains offered by this library (but have yet to use it within a larger real world project, admittedly). Specifically, the TPL exposes dedicated wrappers for the asynchronous programming model (APM), amongst others, so it should be easy to use CIAPI.CS asynchronous requests with the TPL immediately in case (see TPL and Traditional .NET Asynchronous Programming for details) – I think it would be a pity being unable to use this functionality.
    • Since Sky selected to only use asynchronous request internally anyway, there appear to be no significant cost attached to surface this functionality (in fact it would be kinda funny to use async internally, emulate sync and only support sync externally thereafter … – not an argument of course ;)

  7. Is there a way to get further details of exactly what the requests / response header/body is?

    One tooling agnostic option would be a web debugging proxy for request / response interception and introspection: a common and excellent choice is Fiddler (.NET / freeware), but commercial offerings do exist as well of course, with Charles (Java / shareware) being the top most choice on my evaluation list currently.

    Using Fiddler is pretty straight forward with the following three common scenarios:


  8. I’m currently only aware of the respective initial specifications:

    An introductory post by the author Kris Zyp regarding both is available at Pluggable Web Services with SMD.

    There doesn’t seem to be much more around, to quote rwilliams' related answer toJSON-RPC and Json-rpc service discovery specifications:

    Every project I’ve found using this stuff links to the same specs that you’ve found. Folks are using it based on the draft specs, but not enough to really drive the development of good docs and examples.


  9. Interesting question – I’m not used to ‘exemplar’ as a common English term and would have simply read it as a variation of ‘instance’ at first sight; however, the technically more correct interpretation of being a particularly good/noteworthy/special/to be imitated example immediately resonates with me and actually matches the interpretation in German as well: ‘Exemplar’ translates exactly to ‘Exemplar’ and is most commonly used to denote identical copies of something, e.g. I need 4 exemplars of this book; interestingly one would usually only say this for things not easily copied or of particular value, i.e. one wouldn’t say I’d like 4 exemplars of this soft drink – I wasn’t really aware of this subtle difference until you mentioned the subject though. Another common usage would be one of the last exemplars of its kind (regarding a rare plant, animal, or a piece of art), again stressing the difference to your everyday example/instance.

    Consequently Sky’s choice of terminology definitely makes sense to me now, though only after realizing the subtle differences on the fly.


  10. While I see the potential for confusion, I think retries should indeed be taken literally and the current behavior is what should be expected.

    Specifically, one might want to not retry something as well, i.e. just perform a request once and fail thereafter – this would have to be communicated as retry=1 otherwise and pose more confusion I think. Additionally there are related parameters sometimes as well, e.g. retry-delay, which wouldn’t make sense then.

    If you’d prefer to specify the absolute number of requests, the parameter should be called tries instead, see retry (plural retries): Another attempt. in contrast to try (plural tries): An attempt.

    Samples in the wild:

    --retry

    If a transient error is returned when curl tries to perform a transfer,
    it will retry this number of times before giving up. Setting the number
    to 0 makes curl do no retries (which is the default).

    --tries=number

    Set number of retries to number. Specify 0 or ‘inf’ for infinite retrying.
    The default is to retry 20 times, with the exception of fatal errors like
    “connection refused” or “not found” (404), which are not retried.

    So for Wget one indeed has to specify the absolute number of requests (confusingly called ‘retries’ in the explanation) just like you expected, the parameter itself is calledtries though to communicate this.


  11. Are we currently operating in kind of a private beta mode or is it no problem (or even desired) to spread the word already, if there happens to be a respective opportunity?

    I’m asking due to the Area 51 Webservice APIs proposal, which just entered its commitment phase:

    The proposal obviously covers a lot of topics relevant here as well – participating there early could gain some attention for the City Index API initiative, on the other hand it might draw from our still scarce resources right now ;)

     

    Chances/Risks of the Webservice APIs proposal

    I’m still entirely undecided myself, whether all these micro stack exchange sites within overlapping areas will turn out to be useful or not; I see the need for dedicated communities in highly specialized areas, but in general I’d probably prefer tag/filter based approaches within larger sites (currently – this is really a delicate balance).

    To that end I’m sceptical, that the proposal will be successful at all, i.e. it might not gain critical mass to go public or simply get sacked by the powers that be – Webservice APIs is listed as a candidate in Merging Season indeed!


  12. To properly judge implementation design options (in contrast to the HTTP/Json API design itself), the initial minimum platform requirements should be specified/documented. For example, I noticed that JsonClient currently targets .NET 4 and JsonClient.Silverlight Silverlight 4 respectively – does this mean these will be the minimum supported targets for the time being indeed, i.e. .NET 3.5 will not be supported and all .NET 4 goodies are available for the implementation?

    Similar questions exist for other platforms like ActionScript and Java of course, e.g. will Java 6 be required etc.

×