14:20 <hannes> lobo: thx! I'll likely do some more cleanups if you don't mind ;)

14:26 <lobo> hannes: thanks for cleaning up the code. sure, go ahead. after that we can have a 0.0.2 release :D

14:27 <hannes> lobo: I'll tell you once I think we should have a 0.0.2...

14:27 <hannes> lobo: I kept myself busy to develop a logs-syslog reporter... for unix, lwt, mirage... udp/tcp/tls...

14:27 <lobo> hannes: i also started working on topkg yesterday, but luckily haven't pushed the changes. it was good way to learn by comparing your changes to mine

14:28 <hannes> lobo: since you use syslog at work, do you know how on a tcp transport messages are terminated? 0 byte? newline? (I've seen both, but no docs)

14:29 <lobo> hannes: unfortunately i only use udp based syslog at work, but i can run a few tests tomorrow with tcp

14:29 <hannes> lobo: topkg is really neat, esp if you combine it with opam-publish etc... no longer need to push any buttons for releases, just topkg bistro :D

14:30 <hannes> ah cool... do you have a variety of tls-syslog servers ready as well? (I haven't done any interop testing for my tls-syslog stuff...)

14:35 <lobo> hannes: only rsyslog. the majority of the logging is done via logstash, which only supports udp

14:35 <hannes> ic. no worries

14:36 <hannes> I'll figure how to install packages at some point and then do some interop testing

14:55 <hannes> uh, reliable syslog (which seems to specify syslog over tcp) is defined in rfc3195 with some pseudo-xml-markup...

15:00 <hannes> oh nice, found the right rfc for my implementation ;)

15:00 <hannes> http://www.networksorcery.com/enp/rfc/rfc6587.txt

17:19 <hannes> Drup: there's in Functoria_runtime a Functoria_info.info... which is a type, but how do I get the value of the type of the current running application?

17:54 <Drup> hannes: Mirage.app_info

17:55 <Drup> (or Functoria_app.app_info, it's the same)

18:00 <Drup> hannes: Can I assume you volunteer to make the proposed modifications ? :D

18:07 <hannes> Drup: hmm, I don't understand how to use that

18:08 <hannes> Drup: isn't it a runtime value, the info?

18:08 <Drup> Functoria_app.app_info will create a module that contains the value

18:10 <hannes> Drup: could you guide stupid me how to extract it then? in utop, I get a `val f : Functoria_app.info Functoria.impl = <abstr>`...

18:11 <hannes> Drup: (functoria things) I put it on my todo list, but they do not have the highest priority right now... I put it on GitHub thus others might just fix it

18:12 <hannes> Drup: ah, nvm -- there's the app_info example in mirage-skeleton

18:13 <hannes> hmm, no... hannes is too stupid for this

18:14 <hannes> ic, via `~deps:[abstract app_info]`...

18:26 <Drup> hannes: what's the issue ?

18:28 <hannes> Drup: I'd like to get the application name in a library used by mirage (which is not a unikernel in itself)... failing to do so, is there maybe a way to extract the application name somewhere in the mirage tool (haven't tried, not there yet)..

18:34 <Drup> what different does it makes if it's a unikernel or not ?

18:35 <Drup> ah, I see, in a library

18:35 <Drup> make it a functor ? :/

18:35 <hannes> in a unikernel I put ~deps:[abstract app_info] in config.ml, and get an info passed to start

18:35 <hannes> in a library... well yeah... make it a functor

18:36 <Drup> well, you are going to create a device for it, so that kind of dependency would go in the device

18:36 <hannes> yeah..

18:36 <Drup> and if you make it a dependency, it'll be passed to the connect

18:36 <hannes> true... maybe..

18:36 <hannes> I'll look into this soon..

18:37 <Drup> (you don't really need a functor, but you do need to specify the device dependency one way or another)

21:05 <hannes> lobo: (maybe others? mort___?) there's now a logs reporter using syslog (udp/tcp/tls and unix/lwt/mirage) https://hannesm.github.io/logs-syslog/doc/Logs_syslog.html

21:06 <hannes> 5424 (the new syslog syntax) might actually be useful at some stage (maybe tomorrow ;)

21:06 <hannes> also, mirage tool integration so that the users don't have to fiddle around should somehow be done by someone at some point (nevertheless, there is configuration needed from the user, such as remote ip and protocol)

21:38 <lobo> hannes: nice. i'll give it a try tomorrow. just had a short glimpse through the code. in the slevel function, I would map Logs.App to Syslog_message.Informational, since I guess App is just for output you would like to see on stdout normally?

21:39 <hannes> lobo: and error than to critical?

21:41 <lobo> hannes: since logs has fewer levels and you can't have a 1:1 mapping, i would just skip critical. in the end it is up to the collector on how the severity levels are handled

21:42 <hannes> lobo: done, thx

21:46 <lobo> hannes: haven't read 5424 in its entirety, but maybe it would be a good use case for testing angstrom

21:47 <hannes> lobo: for parsing likely... since I'm mainly in generating messages, my job is much easier ;)

21:48 <lobo> indeed :D i remeber skipping the rfc last time, when i read that unicode is supported now

21:49 <hannes> i think unicode is great!

21:49 <hannes> and we have proper unicode libraries in OCaml! :)

21:50 <hannes> I currently use Facility.System_Daemons by default, but would really like to map the log source to an appropriate facility.. still not sure how to do that

21:51 <hannes> with 5424 we could encode tags, and provide more structured metadata, which is a good thing once you think about the consumer of log message

21:57 <lobo> indeed, that would be nice. most applications i've seen just use a custom format for the message part. which means you need to convert it via regexes into structured data on the collector to do something useful with it :-)

21:58 <hannes> that does not sound like the way I want to go

21:59 <lobo> right. also the timestamp field of the old format is not very sufficient. it doesn't carry the year or any timezone information for example

22:00 <hannes> yes

22:01 <hannes> and certainly for parsing, angstrom would be nice... hand written parsers are usually brittle..

22:10 <hannes> maybe with 5424 facility doesn't matter, and a structured id can be used (with the log source name), and a potential UI could depend and filter on that..

22:10 <hannes> (so, my plan is as well to have a collector, and some terminal-based UI for syslog)

22:13 <mort___> (hannes: thanks, will take a look!)