Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 22 16:09
    kaniyan commented #1678
  • Jan 22 16:01
    codecov[bot] commented #1678
  • Jan 22 16:00
    kaniyan synchronize #1678
  • Jan 22 15:05
    codecov[bot] commented #1678
  • Jan 22 15:05
    kaniyan synchronize #1678
  • Jan 22 14:56
    codecov[bot] commented #1678
  • Jan 22 14:56
    kaniyan synchronize #1678
  • Jan 22 14:22
    codecov[bot] commented #1711
  • Jan 22 14:22
    jbtrystram synchronize #1711
  • Jan 22 13:45
    soheilade opened #1717
  • Jan 22 13:15
    sophokles73 commented #1677
  • Jan 22 12:42

    sophokles73 on master

    Increase time out of some unit … Use loop back device for runnin… Migrate unit tests to JUnit 5 … and 1 more (compare)

  • Jan 22 12:29
    kaniyan opened #1716
  • Jan 22 11:29
    codecov[bot] commented #1711
  • Jan 22 10:09
    codecov[bot] commented #1711
  • Jan 22 10:09
    jbtrystram synchronize #1711
  • Jan 22 10:05
    sophokles73 demilestoned #1565
  • Jan 22 10:05
    sophokles73 demilestoned #1558
  • Jan 22 10:05
    sophokles73 commented #1565
  • Jan 22 09:31
    codecov[bot] commented #1672
Thomas Jaeckle
@thjaeckle
correlating requests sent via telemetry to responses sent back via one-way-commands ;)
even when not doing request-response (which I know is not yet supported): it would be helpful to use same correlation-ids in order to track down errors when using Hono + Ditto in combination
even better when the device can choose a correlation-id (e.g. always with a prefix) in order to e.g. find log entries related to such IDs
Kai Hudalla
@sophokles73
ok, not all protocols support the concept of headers vs body, e.g. in MQTT, such properties would need to be encoded in the topic name. Apart from that, Hono does not (yet) generically support the inclusion of "headers" provided by a device in downstream AMQP messages. A generic approach would most likely only support inclusion in AMQP application-properties. Setting the correlation-id would require the definition of a "special" header that we suppirt on all protocol adapters
It would probably be easier to implement this in the message payload, i.e. introduce a structure that distinguishes between meta info (headers) and payload ...
Thomas Jaeckle
@thjaeckle
ok, I get that - sending headers in the payload is of course possible, I just thought that we could influence the "message-id" which we receive for Hono telemetry messages
Kai Hudalla
@sophokles73
I also wonder if it feasible to define the forwarding of client provided headers in commands as a supported concept. Not sure if we could implement this for all protocols ...
BTW we currently use the presence of a correlation-id in a command message as an indicator that this is in fact a request/response command (instead of a one-way command) ...
Thomas Jaeckle
@thjaeckle
hm, for HTTP custom headers would be really cool as default headers like "content-type" or "ETag" or other caching headers might become really useful
ah, I thougt Hono uses the reply-to header as indication that this is a request/response command
Kai Hudalla
@sophokles73
you are right, of course, we use the reply-to header ... it's getting late
Thomas Jaeckle
@thjaeckle
ok, all good then :)
Kai Hudalla
@sophokles73
Can you open an issue for this in Hono? We can then track this better ...
Thomas Jaeckle
@thjaeckle
sure
Kai Hudalla
@sophokles73
@ctron Hi Jens, IIRC you wanted to set up a Doodle poll for finding a date/time for the IoT Packages call/meeting, right?
Jens Reimann
@ctron
Yes, I did that … everyone voted :D
it is today … 16:00 CET
Kai Hudalla
@sophokles73
Except for me, because I didn't follow the issue closely enough?
Jens Reimann
@ctron
sorry, that may be … I only know that Carsten can't join today, he is out of office IIRC
there is also a calendar with the invite
I did however forget to add this to the homepage.
Kai Hudalla
@sophokles73
no worries, found it ...
Kai Hudalla
@sophokles73
@dejanb Hi Dejan, have you been able to take a look at #1647 ?
Dejan Bosanac
@dejanb
@sophokles73 just briefly ... I plan to work on it tomorrow
Kai Hudalla
@sophokles73
cool
Kai Hudalla
@sophokles73
@ctron @dejanb @calohmn It looks like there is only a single place where we still use code from Google Guava: some toString() methods in the Device Registry helper classes. I wonder if we can remove that dependency altogether from Hono ... WDYT?
Jens Reimann
@ctron
hm … while I like the "ToStringHelper" stuff, guava's dependencies are sometimes tricky, so getting rid of it might be a good idea :+1:
that would be a change for 1.1?
Kai Hudalla
@sophokles73
I guess so. Guava is not part of any of our public APIs AFAIK
Dejan Bosanac
@dejanb
+1
Carsten Lohmann
@calohmn
I'm also for removing it then.
Kai Hudalla
@sophokles73
I will create an issue for it then and assign it to @ctron !?
Dejan Bosanac
@dejanb
@sophokles73 how do you wanna proceed with #1647
I have some fixes, but I doubt I can push them to bsinno
Kai Hudalla
@sophokles73
I can push the branch to eclipse/hono as well. We can then work on it together an create a PR from it. Would that work for you?
Dejan Bosanac
@dejanb
yeah ... sounds perfect
Kai Hudalla
@sophokles73
ok, gimme a minute ...
Dejan Bosanac
@dejanb
so basically I have helm chart running (at least getting started looks ok) and systems tests run but I saw a couple of failures
would love to push this to see how it looks in CI and then continue tweaking it
Kai Hudalla
@sophokles73
ok, I have pushed the branch to eclipse/hono ...
Dejan Bosanac
@dejanb
cheers
Dejan Bosanac
@dejanb
new pr is #1651 as I don't think we can edit the old one
I also rebased the branch, so now is mergable
Kai Hudalla
@sophokles73
@ctron would you mind taking a look at #1654 ? It is supposed to be part of 1.0.2 which we want to release this week ...
Jens Reimann
@ctron
done
Kai Hudalla
@sophokles73
@ctron thanks, man :-)
Kai Hudalla
@sophokles73
@ctron @calohmn @dejanb Today is the day we have scheduled 1.1.0-M1 for :-) Anything you got cooking that should be in this milestone in addition to what we have in the "done" column of our 1.1.0 project board?
Carsten Lohmann
@calohmn
From my side that would be #1654. @ctron I've pushed a change to that PR yesterday. Could you have another look?
Jens Reimann
@ctron
@calohmn done … sorry, I assumed you would simply add a comment and merge :grinning:
Dejan Bosanac
@dejanb
@sophokles73 I would like to take a look at the artemis logs
when are you planning to cut it?