klassen-software-solutions / kssio Goto Github PK

Take a look at https://about.gitlab.com/2017/11/27/go-tools-and-gitlab-how-to-do-continuous-integration-like-a-boss/

The basic idea is that with a special comment tag we can parse out the necessary help info.

The idea would be to allow multiple connect() calls in parallel with the first one that is successful being returned and the others being automatically abandoned/closed.

See https://stackoverflow.com/questions/56743962/non-blocking-consecutive-connect-to-two-servers

Should be similar to those for YAML and XML.

Can probably just wrap ntohll

Seems to occur more on Linux than macOs, but I've seen it on the mac as well.

steve@parallels-vm:/media/psf/Home/Documents/Sources/kss/Libraries/kssio$ make check
LD_LIBRARY_PATH=".build/Linux-x86_64/lib" .build/Linux-x86_64/tests/unittest
Running test suites for KSSIO...
  ...........F.
  Passed 12 of 13 test suites, 1 failed.
  Failures:
    poller.cpp: 139, d.numRead() == static_cast<ssize_t>(mydata.size() * 5)
  Completed in 0.022468s.
BuildSystem/common.mk:182: recipe for target 'check' failed
make: *** [check] Error 1

These are items that don't fall easily into one of net/file/stream. They will go in the kss::io namespace.

• error
• init
• poller

These will go into the namespace kss::io::net.

• eai_category
• error
• http
• init
• interface
• socket
• utility

This should be a simple wrapper around the fts methods.

By default it should work as it currently does, but the programmer should be able to specify that hidden files (those starting with a ".") should be ignored.

We cannot yet complete our HttpClient unit testing, although we can test it manually. We need to write a simple HttpServer class which means, hopefully, finding a simple one that we can adapt or use.

Likely written on top of the client/server infrastructure, we would like to provide the programmer with an iostream that is backed by a socket.

This should probably go in the namespace kss::io::net.

something similar to the tee command (but in code) or the go io.MultiWriter

Currently all that is allowed is the ability to parse them. But we should also be able to create them.

We have this for the YAML streaming and should add something similar for JSON.

I would like to expand the build system so that dependancies can be specified and automatically downloaded and compiled when needed. The goals of this would be the following:

• Specify a URL for the dependancy (e.g. https://github.com/yaml/libyaml.git)
• Automatically determine if the dependancy is out of date
• Automatically (or perhaps semi-automatically e.g. "make update-prereqs") download and build the prerequisites.
• Link them statically so they do not conflict/depend on anything else.

These will go into the namespace kss::io::file

• binary_file
• directory
• error
• fileutil
• init

Specifically both "." and ".." are listed by the Directory class. This means that size() will always be at least 2 and empty() will always return false.

These will go in the namespace kss::io::stream.

• error
• init
• jsonstream
• streamutil
• yamlstream
• input and output iterators
• simple_xml_writer
• simple_json_writer

The idea would be to allow the programmer to write to a stream while under the hood the file is automatically broken up based on a maximum size.

See the "add_service_discovery" branch from KSSCore and use it as a starting point.

The goal is to have a simple C++ based front end on Bonjour/Avahi.

The key idea is to allow client or server applications to be written while shielding the developers from the details of the socket and related calls.

Some of the features we would like to see:

• easy to use wrappers around the C calls
• exception based error handling
• lambda based message handling
• client/server code should be independent from each other
• integration will the Poller class.

The current implementation changes to each directory as it creates it, changing back when the entire path has been created. This causes problems when running in multiple threads.

This should optionally be recursive.