Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 24 18:06
    StevenLiekens commented #59
  • Mar 24 18:05
    StevenLiekens closed #59
  • Mar 24 18:05
    StevenLiekens commented #59
  • Mar 24 17:47
    StevenLiekens closed #58
  • Mar 24 17:47
    StevenLiekens commented #58
  • Mar 19 13:02
    Friesinator edited #59
  • Mar 19 13:01
    Friesinator opened #59
  • Mar 18 12:38
    StevenLiekens commented #58
  • Mar 15 15:19
    GHOSCHT commented #58
  • Mar 14 22:01
    Seeker1437 commented #58
  • Mar 14 20:08
    GHOSCHT commented #58
  • Mar 12 15:40
    StevenLiekens commented #58
  • Mar 10 15:46
    GHOSCHT opened #58
  • Apr 15 2018 16:43

    Ruhrpottpatriot on ServiceClient

    Remove superfluous compression … Add simple caching to Core proj… Move files into different folde… and 8 more (compare)

  • Apr 10 2018 21:09

    Ruhrpottpatriot on ServiceClient

    Add fluent api to create HttpRe… Fix Stylecop errors Remove dead code and 3 more (compare)

  • Mar 29 2018 13:11

    Ruhrpottpatriot on NetCore2.0

    Remove disabled and superseded … Delete unused leftover code fro… Move V1.Guild test to appropria… and 8 more (compare)

  • Mar 29 2018 12:17

    Ruhrpottpatriot on NetCore2.0

    Update .gitignore to exclude St… Add Api builder class (compare)

  • Feb 01 2018 09:33

    Ruhrpottpatriot on master

    Refactorize ServiceClient.GetHt… Merge pull request #57 from Kor… (compare)

  • Feb 01 2018 09:33
    Ruhrpottpatriot closed #57
  • Dec 27 2017 17:37
    Korjam opened #57
Steven Liekens
@StevenLiekens
and TcpClient to provide the socket connections as streams
Robert Logiewa
@Ruhrpottpatriot
With that we can reuse the layout and only switch out the connector to implement caching
Steven Liekens
@StevenLiekens
btw HttpClient is already an abstraction
Robert Logiewa
@Ruhrpottpatriot
i know
and strictly speaking you can access the FS by doing a get to a FS URI, but why should we do that?
btw: I want to make as many parts of the app side effect free
Steven Liekens
@StevenLiekens
how many aren't right now?
Robert Logiewa
@Ruhrpottpatriot
the converters should be side effect free
but I'm not entirely sure about the repositories themselves
I need to look into that
Robert Logiewa
@Ruhrpottpatriot
question: Currently there are only two possible chars ({ or [) at the start of an api request, right? Or do we still have an endpoint with envelope?
Steven Liekens
@StevenLiekens
huh
Robert Logiewa
@Ruhrpottpatriot
in V1 we had multiple endpoints who returned something like
"colors": { ... }
Steven Liekens
@StevenLiekens
oh that
Robert Logiewa
@Ruhrpottpatriot
but in V2 we only get back
[{....}]
I need to know the first character, since I have to decide if we get back a collection or not
Steven Liekens
@StevenLiekens
can't you use the endpoint url to decide that
Robert Logiewa
@Ruhrpottpatriot
i could, but I have a better idea
since I changed the layout, the connector does not need to know into which type we convert the data later on
and we have an X-Result-Count
also if I change the request url from e.g. v2/colors/{id} to v2/colors?ids={ids}, even if it's just one
I always get a collection back
so I just need to write a Slice object
Robert Logiewa
@Ruhrpottpatriot
This message was deleted
Robert Logiewa
@Ruhrpottpatriot
Question: What do you think of a small DSL to describe queries? Here's the reason why:
Currently I have the ApiRequest class, which stores the resource's location and additional parameters. However we have many parameters which are only valid for a single node, e.g. signature, file_id and format are only valid for the render service. Of course we could add them to the ApiRequest object. However then we'd have many unused properties. We also could change the ApiRequest to only have the location and everything else is set via KeyValuePairs. But that'd mean passing around magic strings.
Your thoughts?
Robert Logiewa
@Ruhrpottpatriot
On a sidenote: Have you tested out VS 15 yet?
Steven Liekens
@StevenLiekens
I tried an early preview but I haven't really looked at what's new
Biggest thing seems to be that VS 15 can open directories without requiring a solution or a project file?
Which is good but not earthshaking
Anyway about the API
Steven Liekens
@StevenLiekens
Don't forget to kiss
Our own DSL would be overkill
Steven Liekens
@StevenLiekens
We're here to make it easier to use the API, not harder ;)
Robert Logiewa
@Ruhrpottpatriot
yeah, I quickly saw that too. Writing a DSL would be too tailored for an HTTP connector. So I switched to a (simple) expression tree under the hood. This does not mean however, that a user who's just using the library will ever see them. The front end is a simple fluid interface, that does the work under the hood.
And if you want to write your own connector, you should be able to at least grasp the basics of expressions trees, since they are a big part in LINQ providers.
This message was deleted
This message was deleted
This message was deleted
This message was deleted
This message was deleted
This message was deleted
This message was deleted

I'm not aiming for an IQueryableimplementation, so the interface will be simple enough. As it stands, you can write Queries like this:

var builder = new QueryBuilder();
builder.AtLocation(() => this.Location).WithParameter(() => this.Parameter);

Then you'll get an expression tree which is converted into the proper request. You can also chain them as you like.

Steven Liekens
@StevenLiekens
so a fluent API
not really a DSL :)
oh
I shouldn't read from bottom to top :)
Robert Logiewa
@Ruhrpottpatriot
yeah, that can be a bit misleading :P
I need to revise the structure a bit, since at this moment we won't be needig extension methods anymore, as you just change parameters in the repository and do a query. The connector or the repository itself is going to piece the parts together.
Robert Logiewa
@Ruhrpottpatriot
You know, one should not dispose of HttpContent, when you are going to need it later...