Hi everyone. We are pleased to make available an open-source C# library for doing the new SCRAM haystack authentication. You can find the source code here:

https://bitbucket.org/skyfoundry/haystack-csharp

This is a very minimal implementation that currently only solves the authentication problem. We hope that in the future, we or members of the community who do a lot of .NET development will enhance it to support the full haystack data model.

Hi Matthew Good work! I've fixed basic auth and compatibility with nhaystack. https://bitbucket.org/minzdrav/haystack-csharp/commits/3f1b05568854ad4faeb17bdc2161151774f77c55

How we can integrate my changes to your repository? Btw, I would be happy to see your library on nuget.

Hi Andrey - can you issue a pull request or send me a patch directly (I will email you offline)? I will try to get in incorporated as quickly as I can.

Hi Matthew. You can find patches in email message. Thank you for quick response.

@Andrey - Thanks for the patches. I pushed them to the repo and they are available now.

Perfect!

Hey Matt,

Using the latest haystack-csharp version I seem to be having issues getting a json response from a server which is using haystack v2.0. The code below returns a result in the text/zinc format:

var uri = "http://someserver.com/api/demo/";
HClient hsClient = HClient.Open(uri, user, pass);
Dictionary<string, string> searchParams = new Dictionary<string, string>();

string result = hsClient.GetString("about", searchParams, "application/json", "application/json");

Console.WriteLine($"Result:\n{result}");

Using the RestSharp library and code below against the same endpoint I am able to get the expected json response:

var client = new RestClient("http://someserver.com/api/demo/about");
var request = new RestRequest(Method.GET);
request.AddHeader("Accept", "application/json");
request.AddHeader("Authorization", "Basic user:pass");

IRestResponse response = client.Execute(request);

Console.WriteLine($"Result:\n{response.Content}");

Let me know if this is not the proper venue for questions on the library. Happy to help contribute where I can. Thank you for your time.

-Tyler

Tyler - that is weird. Seems like you are doing the right thing. For this particular project I am more than happy to receive patches from the community. The BitBucket repos is at haystack-csharp. If you are able to debug it and come up with a fix, let us know, or send a pull request to that repo.

Hey Matt,

The haystack endpoint I was working with actually had two API endpoints. The one they were using for testing was the one not returning a proper json response so the issue I was seeing was not related to the haystack-csharp library. I was however able to find an improvement along the way and sent over a PR. Thank you for the help.

Thanks Tyler - I merged in your PR.

Hey Matt,

I have recently interacted with a 3rd party haystack v3.0 compliant server using this library. Presuming the HClient requests a json response, this lib's current implementation sets the Accept header to:

Accept: application/json; charset=utf-8

The assistance I need here is to confirm whether the charset=utf-8 portion for v3.0 should be presented in its own Accept-Charset header.

Stated another way, should the following Accept header be considered both haystack v2.0 and v3.0 compliant:

Accept: application/json; charset=utf-8

Happy to send over another PR to correct if needed.

Thanks, Tyler

Hi Tyler - So I'm assuming the issue is that the remote server does not like the charset=utf-8 being part of the mime type?

I think it is probably a bug to for the .NET library to force appending charset=utf-8. You can include that in the mimeRequest parameter of the HClient.PostString if you need to.

I'd be happy if you sent a pull request to correct this. Thanks!

That is correct. Adding charset=utf-8 to the Accept header causes their v3.0 implementation to return text/plain instead of application/json as the Content-Type in the response. I'll send over the correction for both HClient.GetString and HClient.PostString.

In addition, there is another minor correction to include in HClient.OpenHttpConnection along with some formatting. What code formatting freedoms might I assume? Is there a particular standard I should follow or are the standard VS 2017 format settings acceptable?

Hi Tyler - as far as code formatting, I would try to follow whatever we have in the files right now.

I'm not a .NET developer so I'm not sure what the standard conventions are. If you think the source is way off in terms of standards, I could see doing a separate pull request that just does reformatting. But don't mix formatting changes with bug fixes. Thanks!

@Tyler - FYI - I merged in your two outstanding pull requests. Thanks for contributing.

Hey Guys,

First of all - Thanks for this awesome .NET connector. It works beautifully!

Problem

Just wanted to point out something I ran into - I had an issue when using toJson(), where it was throwing an UnknownNameException: <ColumnName> error when the column name was null in the returned HGrid.

It was working fine with ToString() and toZinc() functions but throwing this error just for the toJson()

This was probably due to the function get in HRow.cs (line 75 - 85) which was -

// Get a cell by column.  If cell is null then raise
//    UnknownNameException or return  null based on checked flag. 
public HVal get(HCol col, bool bchecked)
{
    HVal val = m_cells[col.Index];
    if (val != null) return val;
    // Ian Davies - .NET port - this could cause a unknown name exception
    //              for a null value - back to previous comment
    if (bchecked) throw new UnknownNameException(col.Name);
        return null;
}

I believe this is good / the intended functionality with the bChecked parameter.

But I noticed that in line 148 of HJsonWriter.cs, we get HVal by doing the following

HVal val = dict.get(name);

Because of this, the bChecked value was getting set as true by default and it was causing the error.

Solution

So I did this to fix it -

HVal val = dict.get(name, false);

Since this is a super minor fix, just wanted to point out here (if you guys would like to fix it from your end instead of a PR).

Once again, thanks for this connector. Awesome work!

Hi Aswin,

Thanks this small issue fell through the unit tests and have not had time to further my own project where I am looking at using the .NET client, so did not notice it in furthering my own application use. Created a pull request to merge this change after completing the unit tests after making the change (sorry got the name wrong looking at the thread prior to this one when making the changes in sourcetree - my apologies)

Thanks again for your finding and complements on the work done to this library.

@Matthew you should find a new pull request for this with the change.

Kind Regards

Ian Davies

@Ian @Aswin - I have merged the pull request in that contains this fix

Forecast hisWrite()

Hello is there any option how to utilize forecast with c# .net library ? hisWrite is implemented only as hisWrite(Href,data). Also HisWrite seems to not write any data which have future datetime.

Thanx for any info.

Hi Martin - It sounds like you might be trying to use the library to work with SkySpark. "forecast" data is a feature of SkySpark histories - it is not project-haystack concept. If you are trying to interface with SkySpark, I would suggest posting your question to their forum.

Also, the behavior of hisWrite will depend on the server implementation. SkySpakr will allow you to write future data, but the "demo" database has a setting that disables future writes. If you remove the "demoMode" tag from the his ext record, then it should work. Or create a new proj (don't use demogen) and it should also work.

Hi Matthew,

First of all, thanks for this library! We are just starting out with SkySpark and appreciate having an out-of-the-box library we can use to interface with the database.

However I have some features I would like to see added to the library:

• .NET Standard support, like this fork: https://bitbucket.org/soccermitchy/haystack-csharp-netstandard/overview
• A NuGet package to more easily integrate the library into our projects and manage updates.
• Async methods to use parallel processing.

If possible I would like to contribute to this library rather than having to create my own (or fork it). Can you please let me know what the possibilities are?

Hi Chris - I would be happy to incorporate pull requests that do all those things. The initial project was to get something usable out there. If you look at the project history in bitbucket you will see that I have already incorporated a number of pull requests from the community.

So if you have implemented any of those changes please send me a pull request. That is the standard workflow for merging changes from the community in an open source project. In case you are not familiar with that workflow, at a high level you would

1. Fork the project to your own repo
2. Do your enhancements on the fork (typically on a branch)
3. When you are happy with the code and ready to submit it back to the community push your changes to your fork and then issue a pull request.

Hi Matthew, thanks for the quick response! For points 1 and 3 I will create PR`s shortly, however for point 2 (NuGet packaging) I believe it is best if this is done from the main development branch. Will you be looking into this, or can I be of assistance?

@Chris - I can look into NuGet publishing. I'll wait for other pull requests before looking into that though.