The last one was: #34

from akka-meta.

cc @akka/akka-http-team @akka/akka-team

from akka-meta.

Time works for me. I'll try to actually join this one :-)

I'd like to talk about streaming marshalling support, see akka/alpakka#63 akka/akka#21826

from akka-meta.

Yes, good idea!

from akka-meta.

Will you put a link in this ticket to the hangout?

Being mostly involved in the documentation improvements two things come to mind: status of akka/akka-http#11 and akka/akka-http#527 (with related Paradox tickets)

from akka-meta.

Will you record this time as well? I will miss the call, because of work.

from akka-meta.

sure

from akka-meta.

Here's the link to the meeting: https://www.youtube.com/watch?v=Z_AktNMcomU

from akka-meta.

Actually I can't attend (yearly nikolaus family "encounter").

However what would be good to disuss, would be when and how to actually make the client a little bit better.
I worked again on my play-ws akka-http implementation and worked with the java side and found out that it's really hard to do some things in Java, especially when it comes around typesafe headers, or resolving the absolute uri gained from a location header via Java (you need to use a internal api..) (no documentation around such stuff for java, etc). But it would be great to actually collect all the things first and how it could be improved (and clean up the issue tracker with it).

from akka-meta.

Yeah, absolutely agreed the client is nowhere near where it should be. In the lightbend team we won't have any time to focus on it other than bugfixes I fear. Good idea to try to put together things that need to be addressed. Could you open tickets for the issues you found @schmitch ?

I'll add a discussion point to the call

from akka-meta.

I might not be able to make it, since I'm ill in bed.

from akka-meta.

Hang in there, hope you'll get well soon 😷

from akka-meta.

I will not be able to make it because of work 😞
One point I'd like to bring is the Java DSL, even though it's good and it does mainly the same as the Scala DSL, there are cases where as a Java Developer you can feel slightly second class user of Akka-Http.
I think we need Java DSL to be at par with the Scala DSL if we want to get bigger adoption for Akka-Http.

from akka-meta.

@ktoso actually I didn't had time to create tickets yet / clean up what I collected, but here is a not yet complete list (some things is probably discussable (and some stuff is maybe not correct due to the lacking documentation):

Resolving a Header

JavaUri is internal and the code is overly verbose

Optional<Location> location = response.getHeader(Location.class);
return location.map(l -> {
    Uri redirectUri = l.getUri();
    if (l.getUri().isRelative() || l.getUri().isEmpty()) {
        redirectUri = new JavaUri(((JavaUri)l.getUri()).uri().resolvedAgainst(((JavaUri)request.getUri()).uri()));
    }
    return execute(request.withUri(redirectUri));

--

Parsing key: String, value: String headers in java

impossible since HttpHeader.parse is not really callable from java due to a default method,
even if you try to you see that there is a lot of private[akka]/private[http stuff] maybe there is another way,
but I couldn't find it.
actually this is mostly used to call into legacy code
(one could use RawHeader for everything, but I guess that makes no sense if you could just parse it and
validate it with that, you could even throw a exception if something fails)

    headers.asScala.flatMap { case (key, values) =>
      values.asScala.map(value => HttpHeader.parse(key, value))
    }.flatMap {
      case ParsingResult.Ok(header, _) => Option(header)
      case _ => None
    }.filter {
      // Filters the Content-Type that is already applied to the HttpEntity
      _.isNot(`Content-Type`.lowercaseName)
    }.map(v => v: jm.HttpHeader).toBuffer.asJava

--

java header models have no static name() field like the scala ones

ModeledCompanion contains it, which wouldn't be a problem since some scala headers can be used in Java,
however it's really hard to actually call Content-Type.name() from Java without using $ encoded methods...

--

ContentTypes/MediaTypes (scala and java) should be better explained

I guess a lot of people don't actually think it's easy to construct it.
Before they were just used to think of a content-type as "text/plain" or "application/json".
However akka-http enforces Binary/NonBinary/OpenCharset/Compressibility etc.

The only simple type is MediaTypes.lookup(mainType, subType) which gives back a Optional
but that will fail, if it is not known before. (Probably something like RawHeader would be useful here).
A lot of this class is not documented and has no JavaDoc/ScalaDoc.

(luckily most Media Types are inside MediaTypes already, so it's even easy to generate a ContentType)

--

Missing Documentation / Verboseness

missing documentation makes some things really really hard to figure out (javadoc/scaladoc is not enough).
I guess Multiparts is probably a well known example of that since for a simple 1 file + FormData you need to:

        Map<String, String> dataMap = new HashMap<>();
        dataMap.put("hello", "world");
        RequestEntity entity = FormData.create(dataMap).toEntity();
        Multipart.FormData.BodyPart bp1 = Multiparts.createFormDataBodyPartStrict("hase", (HttpEntity.Strict)entity);
        Multipart.FormData.BodyPart bp2 = Multiparts.createFormDataPartFromPath("blabla", ContentTypes.APPLICATION_OCTET_STREAM, new File("").toPath());

        Multipart.FormData mpf = Multiparts.createFormDataFromParts(bp1, bp2);
        mpf.toEntity("boundary");

Maybe there is a simplier way, but I couldn't find one? (Btw. the server side looks extremly verbose as well).

from akka-meta.

Wow this is the most confusing UI on the planet...
This is the right link for talking: https://hangouts.google.com/hangouts/_/ytl/6ijUMp6iQIysGXYR8w4_QPEc4BUdNfcQ2oF2wtEgJO4=

from akka-meta.

Video from this call is available for your viewing pleasure here: https://www.youtube.com/watch?v=Z_AktNMcomU 😉

We discussed the above points.
We thought discussing the streaming thing would be best once @jypma is present, so let's do it next time.

Thanks everyone!

from akka-meta.

All good points @schmitch - let's make them tickets :)

from akka-meta.