Прочитал ещё раз и подумал. Лучше сделать какой-то проект на

блокчейн. Ну найти инвесторов само-собой, потому что инвесторовать в это свои деньги нельзя.

Если уж не блокчейн, а всетаки касса то:
1. Лучше взять .net.
2. Лучше взять коробочный дистр линукс.
3. А если у нас .net и UI то может лучше старый добрый Windows Forms.
4. А если Windows Forms, то лучше и windows поставить, к чему эти извращения с Linux и Rust.
5. Продолжая логику, база данных подойдёт Microsoft SQL Express.
6. Обязательно ORM, ну как-же без него.
7. Обмен данными с кассовми сервером вполне подойдёт xml, тем более в .net есть отличный серелизатор.

А потом:
-- Ребята, а почему у нас пять тысяч товаров выгружается час?
-- Понимаете, это большой объём данных, требуется много ресурсов обработать его.

-- Ребята, а почему касса не переживат три отделения питания?
-- Ну понимаете, это сложная вычелиьеяная техника, она не должна такое переживать.

-- Ребята, у нас две клавиатуры, как откличить на какой именно нажали кнопку?
-- Архитектура ядра это не позволяет, да и вообще вам это не нужно, потому что это нигде не работает.

......
Впринципе знакомый стэк, знакомые проблемы, известные решения (в основном одно решение, говорим что так и нужно).

Про две клавиатуры.. У винды есть multiseat решение.. Это Виндоус сервер, который открывает rdp на локал хост....

Это про сканер штрих-кодов в разрыв клавиатры

Тоже забавная штука, тупо как клава работает, да

Че.. обмен данными в хмл? Вы из 00х?

такого есть много до сих пор, те же платёжные системы в десятках

Ннт, это не то. Я имею ввиду ситуацию когда к компу подключено две клавиатуры и нужно отличать на какой нажали что-то.

А нужно в json?)

Почти но не совсем. Есть две клавиатуры кассира, они с ридерами магнитных карт. Нужно знать на какой считали карту, в зависимости от того где считали разная логика, определённый вид карты должен считыватся на определённой клавиатуре. Так-же ввод с определённой клавиатуры нужно отличать и по разному обрабатывать.

Да

Полагаю что никакой разницы в каком тестовом формате гонять нету. Все это одинаково не эффективно, а замена xml на json это мода. Данные представленные в виде tlv структуры, без преобразования в текст всегда будут эффективнее чем текстовые форматы. Есть Messagepack, Protobuf. Ну это если хочешь по быстрому и готовое. Я понимаю что есть ублюдочные платформы вроде nodejs или 1С Предприятие где невозможно эффективно записывать объект в двоичнй вид, но к rust это явно не относится. Json только чуть хуже читается, хотя если серелизовал робот, а не человек опиывал формат то абсолютно не важно, разобраться что в xml с миллионом неймспейсов что в json с десятом-другим вложений невозможно одинаково. И нет, по моему мнению не нужно в json.

Json парсить легче, на самом деле. А ещё он легче xml. Однако да, это тоже самое и на долгой дистанции абсолютно всё равно что использовать

А, в том смысле что парсер будет проще и быстрее работать? Тогда понял, согласен. Я часто сталкивался с ситуациией когда по сути таблицы запихивают в json, из-за того что в каждой строке назвая полей оно раздуваетя неимоверно. Был один случай, когда в таблице был 32 bit ID, и 48 Bit битовая маска, каждой бит отвечал за какие-то свойства. В json это упаковли с именами свойств и это было просто прекрасно на 500 тысяч элементов. Заказчик искренне уволился насколько оно может быстрее работать если сделать пакет в котором просто последовательно два значения фиксированной динны, а в начале пакета количество элементов.

Да это всё не раствэй проблемы. Есть серде, который поддерживать практически любой формат будет.