Show HN: Poser – Posix SERvices C framework | Hacker News Reader

Show HN: Poser – Posix SERvices C framework

zirias.github.io

30 pointskazinator10 comments

From a cursory glance this seems to be a contender for libuv, so I would like to learn more about motivation for this project. Unfortunately, none is given, as well as why is it limited only to POSIX APIs.

It certainly is not. Libuv (and friends) abstract platform-specific APIs like epoll (Linux), kqueue (FreeBSD), IOCP (Windows) etc, allowing to scale up to lots of concurrent clients/connections. I would recommend to use such a library for anything where you'd ever expect having to handle more than maybe 100 concurrent clients.

This is a small and simple alternative (the only similarity is offering some event-based API) using nothing but POSIX. This allows to keep the code small and avoid conditional compilation (so far only used for the optional TLS support). You might want to use it when you want to write some "small" service for POSIX systems, and focus on your actual logic (e.g. your protocol implementation) instead of dealing with all the internals of handling sockets, name lookups, daemonizing, signals, threading where needed, and so on.

A bit more info also here: https://groups.google.com/g/comp.unix.programmer/c/qsxDODLNe...

POSIX doesn't define a service API for (HTTP, local, or otherwise exposed) services, but if adherence to an existing API spec from the height of SOA is important, there is Service Component Architecture (SCA) which has bindings to C (or other native PL), Java/JVM, and other relevant calling conventions. There used to be multiple implementations of SCA for C++ (Apache Tuscany, Trentino/Siemens, and others) but C++ name mangling is of course a PITA for binary forward compatibility.

I apologize, but how is this relevant?

Just looking at the Wikipedia page for this standard makes it really clear why it has never seen widespread adoption (and I, for one, am really happy it didn't).

The project OP is referring to instead adheres to a very small, very clear spec, and not in the sense of implementing it. Instead, the project seeks to provide a set of tools using this limited spec.

I have my own set of criticisms for the OP, but this just doesn't make any sense.

A "service" certainly doesn't mean SOA (using SOAP), it doesn't even mean any specific form of communication (there might be cases not needing any communication), it basically just means some hosted piece of software.

The idea of the "core" part of "poser" (the only one implemented so far) is to provide a framework (and toolkit) to easily implement your service targeted at hosting on POSIX platforms. Among other things, it does offer abstractions for socket communication of the STREAM type, as this is what many services will use for communication. At this low level, it is completely protocol agnostic. All that's offered is some convenience API to tell the connection what's expected to be received next: binary data (optionally of a specific size) or strings/text with any strategy to find the end of the message (offering an implementation finding typical "line endings" as this is what many text-based protocols use).

I might add more libraries to "poser" in the future, e.g. to offer HTTP functionality.

SOAP is one thing that certainly won't be added though. SOA is dead. IMHO, rightfully, it's just an over-complex mess. When you offer HTTP-based services nowadays, you typically use REST semantics (using the verbs offered by HTTP for the actions, working on resources identified by the URI). For the documents exchanged in a REST API, JSON is a popular format choice. I don't know whether I will implement anything supporting communications using HTTP/REST, but that might be an option one day.

This looks really useful! I've just started working on a (mostly pedagogical) little project making a chat server/client in C and started reading through Beej's guide to networking which is great for the fundamentals but I was struggling with deciding how I want to structure my larger code in terms of sockets, clients, multiplexing, etc. I may just end up using your library if it fits (after reading through it some more), else take inspiration from it at the very least.

Thanks!

If your goal is learning yourself, I guess you should really implement your stuff down on the system API level (using sockets and so on) ;)

If, OTOH, you want to get up some simple/small service quickly, I hope "poser" can help. I'm not sure the docs are already "good enough" (it's still a very young project ...) -- there's also a real example using it here: https://github.com/Zirias/tlsc/blob/master/src/bin/tlsc/tlsc...

Poser: The ultimate insult a skater could call anyone else.

Mall grab

Industry plant

Friends don't let friends push mongo

Not exclusive to skaters. It was used in the 1980's by members of more genuine, legitimate subcultures to disparage members of shallower, more phony subcultures. E.g. thrash metal musicians regarded glam rockers as posers.

According to Douglas Harper's etymonline.com, "poser" meaning "one who practices an affected attitude" goes back to 1881, and was revived in teenager slang by 1983. "poseur" with the same meaning precedes "poser" by a little bit.

Reply on news.ycombinator.com