Determine binary protocol for HSlice to request contours at various angles.

[julialongtin]

When HSlice gets to the point of requesting non-planar slices, we will be losing data in the STL format. support a method where hslice can connect to implicitcad, and request slices along planes, so as not to lose this information.

RESEARCH: is there any tool that does this already, so that we don't have to invent a new "give me an SVG" communication protocol?

[mirage335]

https://github.com/colah/ImplicitCAD/issues/263

MetaEngine was created to provide a structured means of interprocess communication as generalized as possible, without the single-input-single-output limitation of typical anonymous UNIX pipes. And to do so without the potential pitfalls of a centralized server application like DBUS.

# Creates temporary '.m-UUID' subdirectory in same directory as script.
_start_metaengine_host

# Input is '< /dev/null' .
_set_me_null_in
# Output is random directory - like an anonymous pipe.
_set_me_rand_out
# One of your programs connecting to these directory/file 'pipes'.
_example_processor_name

# Swap previous output directory for current input directory, and declare another random output directory.
_cycle_me
# Another one of your programs connecting to these directory/file 'pipes'.
_example_processor_name

_cycle_me
_example_processor_name

_cycle_me
_set_me_null_out
_example_processor_name

# Delete temporary directory safely, etc.
_reset_me
_stop_metaengine_wait

Named pipe variation is demonstrated here, where the '_assign_me_name_out "1" ' function is used to set/override 'random/anonymous' pipe directory/file assignment. https://github.com/mirage335/ubiquitous_bash/blob/master/metaengine/example/example_metaengine_chain.sh#L25

So now you can do whatever you want. You could use a named 'pipe' directory to write new 'query' files (ie. query-date-UUID) that are read in order by the receiving 'server'. Your 'server' could write out framebuffers, using an atomic move operation or confidence indicator like these bits of shellcode .

https://github.com/mirage335/ubiquitous_bash/blob/master/metaengine/typical/typical_metaengine_page.sh#L201 https://github.com/mirage335/ubiquitous_bash/blob/master/metaengine/typical/typical_metaengine_buffer.sh#L112

In this case, I think you would be sending queries to receive the desired data in all possible formats, resulting in something like this in the server's input/output directory.

1. Query file received in input directory.
2. Query file read, then deleted (client can infer message received).
3. Server creates a new output subdirectory, sends all possible forms of the data (SVG and otherwise) to that directory.
4. Server changes a symlink so programs start reading from new output directory.
5. After a reasonable time interval, old directories are deleted. In a non-realtime system, this is defined as excessive disk usage, and clients should slow queries to avoid resource exhaustion. Ideally, at least some clients would use specifically named query files (ie. query-hslice-date-UUID), so servers could prioritize if necessary. In a realtime system, queries and responses would be simply dropped after too many missed 'ticks'.

Vast majority of UNIX systems have a ramdrive mounted somewhere with end-user permissions similar to '/tmp', and MetaEngine as part of Ubiquitous Bash can use that as the temporary directories, though this has rarely proven desirable on modern systems.

Doing everything like this, where everything is a file/directory, and everything is managed by a completely portable bash script, is much simpler than implementing a network protocol and server to query for specific data within a perhaps opaque database. Diagnostics are also much easier, because each program is free to write verbose debugging information of all types into the output directories, which receiving programs can simply ignore.

However, such a network protocol/server may be connected to this system of 'pipes' as well.

[sorki]

@mirage335 that's interesting but I think the question of transport is not that important for now. In Haskell most protocols are based on data types and it's quite easy to automatically serialize the data type to binary, json.. Only after that the question of transport arises and it's quite easy to do multiple too. You might find my implementation of ZRE protocol interesting for that matter (https://github.com/sorki/haskell-zre) which is a distributed protocol based on ZeroMQ (and also https://github.com/zeromq/zyre and https://github.com/zeromq/pyre for C/Python variants).

I don't know of any existing protocol that does what @julialongtin asks for.

[mirage335]

Ah, I think I see. This is a how to get a data format in/out of Haskell problem first, and only later a problem of creating a protocol for handling that data.

The ZeroMQ and ZRE protocol implementations are interesting indeed. Much of my reasoning for file/directory interprocess communication is to provide such things as environment variables that keep everything contained to the script's own directory, which is helpful for portability and is not limited by available network ports. Looks like ZeroMQ and ZRE may have their own mechanisms to provide similar capabilities, so that is definitely worth a look.