Show HN: Poser – Posix SERvices C framework
zirias.github.io
Show HN: Poser – Posix SERvices C framework
1–10 of 11 posts
Re: Show HN: Poser – Posix SERvices C framework
#2Poser: The ultimate insult a skater could call anyone else.
Re: Show HN: Poser – Posix SERvices C framework
#3Poser: The ultimate insult a skater could call anyone else.
Mall grab
Industry plant
Friends don't let friends push mongo
Re: Show HN: Poser – Posix SERvices C framework
#4This 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.
Re: Show HN: Poser – Posix SERvices C framework
#5POSIX 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.
Re: Show HN: Poser – Posix SERvices C framework
#6Poser: The ultimate insult a skater could call anyone else.
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.
Re: Show HN: Poser – Posix SERvices C framework
#7POSIX 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++ nam…
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.
Re: Show HN: Poser – Posix SERvices C framework
#8From 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.
Re: Show HN: Poser – Posix SERvices C framework
#9From 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...
Re: Show HN: Poser – Posix SERvices C framework
#10POSIX 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++ nam…
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.