DataModel over TCP/IP

Я особо не вижу смысла в этих моделях.
Так как модель должна быть представлена на 2 сторонах, а вот использование qt в качестве сервера немного ограничивает и не оправдывает себя. Если это будет не так, то стандартных моделей более чем достаточно.

использование qt в качестве сервера немного ограничивает

Раскроете вашу мысль более подробно?

оффтоп: А что стоит читали по MVC в Qt?

http://qt-project.org/doc/qt-4.8/model-view-programming.html

throw? Оператор запуска исключения?

Я имел в виду через. Через TCP/IP.

Как это правильно написать на английском?

[offtop]Один из переводов слова throw - набрасывать.[/offtop]

Как это правильно написать на английском?

via, through.

Один из переводов слова throw - набрасывать.

Ну-ну.

through

Именно его и имел в виду, но ошибся с написанием.

Давайте честно, Qt это говно. Хотя-бы потому что нет нормальной системы отслеживания ошибок.
Может быть там есть соглашение о кодах возврата и кодах ошибок, которое можно использовать для единообразной и логичной отработки отказов?
Или там есть эксепшены, которые позволяют сделать ленивую обработку ошибок, каскадирование и разворот стэка?
Или там все объекты автоматные и не позволяют выполнять методы вне конкретных и чётко описанных состояний, а также имеют четкую систему отслеживания состояний и распространения ошибки?
Подождите, там есть классная штука! При ошибках в ран-тайм на консоль высыпаются сообщения об ошибках! Вот это я понимаю, технология!
И ещё, у объектов есть куча методов типа isReadable,isWritable,isЧтоТоable. Типа хочешь записать - проверь можно-ли, если нельзя - можешь выполнить код, который отработает такую ситуацию, к примеру выведет в консоль сообщение «типа ошибка».
А чего только стоят сигналы, которые в случае присоединения слота по BlockingConnection являются синхронными функциями, в случае QueedConnection отложенными асинхронными
(Хотя у них хорошо получилось организовать реактивность ModelViewFramework с помощью этих самых сигналов) ?
И как следствие жуткая помесь side-эффектов, порождаемых разными участками кода. Вот этот участок кода меняет конфигурацию создаваемого объекта, и будет выполнен в конструкторе в функции main, а вот этот участок вызывается в слоте и будет выполнен только в момент работы EventLoop. Вот этот метод мы делаем обычным синхронным методом, вот этот будет реализован в виде слота, а вот это у нас виртуальная функция-обработчик события, которая будет вызываться из EventLoop когда мы запостим своё сообщение через PostEvent.
Ребята вместо того чтобы разрабатывать логичные и понятные примитивы, из которых можно как из кирпичиков строить своё приложение, а также логичное и понятное центральное ядро - попытались предоставить функционал для решения «типичных», как им казалось задач. Вот к примеру, реализовали они у себя «конечные автоматы», а для чего? Эти автоматы малопригодны для чего-либо кроме как для решения тех проблем, которые появились у них при создании интерфейса со сложной автоматной логикой. Почему они не реализовали, к примеру что-то типа boost::program_options, которую сегодня на хабре(не к ночи будь упомянут) нахваливали, а сделали только куцый парсер конфиг-файлов в виде QSettings?
Пытались прыгнуть выше чем библиотечка для построения GUI? Как-то не вышло. И всякие попытки сделать на ней что-то, отличное от стандартного desktop-gui будут напоминать упорное жевание кактуса и кучу магии.

куцый парсер конфиг-файлов в виде QSettings

Отлично справляется со своими задачами. Если вам необходимо что-то больше - пишите или используйте готовое. Никто вам не запрещает.

Давайте честно, Qt это говно.

Мы учтем ваше мнение.

А чего только стоят сигналы, которые в случае присоединения слота по BlockingConnection являются синхронными функциями, в случае QueedConnection отложенными асинхронными

Это отличное решение, если _уметь_ им пользоваться.

нет нормальной системы отслеживания ошибок.

У меня нормально получается отслеживать ошибки. Какая конкретно ситуация у вас сложилась, что вы не смогли этого сделать?

У меня нормально получается отслеживать ошибки

ЗдОрово! Подскажите как?!
Ситуации то мы, дай бог, разрулим. Меня интересует общая стратегия.
Неа, ну я конечно понимаю что они рекомедуют стратегию:
- почитать мануал про объект, узнать когда и как можно вызывать функцию
- вызвать все isXXX у объекта,удостоверившись чтобы он был точно в том состоянии, в котором функция гарантировано вернёт результат
- вызвать функцию
- вызвать waitXXX, если функция не дай бог асинхронная (о чём не забыть прочитать в документации, где где-то между строк это будет указано )
- проверить результат и коды ошибок, для определения корректности читать документацию и исходники

Но как-то слишком замудрёно получается. Вам не кажется?

читать документацию

Именно. Не совсем понимаю, о каких сотнях isXXX вы говорите. Приведите конкретный пример функции, для вызова которой необходимо осуществить большое количество проверок.

Пытались прыгнуть выше чем библиотечка для построения GUI? Как-то не вышло

Что не вышло, например, в QtNetwork и QtSql ?

Нет, лучше вы расскажите как вы ошибки и отказы обрабатываете

Вы заявили, что зачастую для вызова какой-то функции необходимо вызвать кучу isXXX.

Вы можете свои слова подкрепить *конкретным* примером (желательно 2-3 примера) или нет?

А Вы заявили что отлично обрабатываете ошибки в Qt, причём раньше чем своё заявление сделал я. Так что в первую очередь жду от вас ответа, а то вдруг я не прав.

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

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

как вы ошибки и отказы обрабатываете

Вы про какие ошибки ведете речь? Дайте пример, что ли.

Обрыв TCP-соединения.
Удаление с диска читаемого файла.
Alter Table в СУБД в то время как таблица загружена в Qt.

Дальше сами можете придумать.

Вы заявили что отлично обрабатываете ошибки в Qt, причём раньше чем своё заявление сделал я

Читаем ваше первое сообщение в теме

И ещё, у объектов есть куча методов типа isReadable,isWritable,isЧтоТоable. Типа хочешь записать - проверь можно-ли

Так что сейчас вы откровенно лжете, что наталкивает меня на мысль, что лгали и во всех остальных сообщениях.

Также, отсутствует соглашение о том как вообще передавать данные по сети в общем случае

Использование QVariant решает эту проблему.

Если вы имели в виду какой-то более-менее стандартный способ проброса данных через сеть

Я имел в виду не какие-то сферические данные в вакууме, а данных из конкретной модели, спецификация которой (индексы-описатели полей) доступны клиенту и серверу на этапе компиляции.

trex
прощайте

пока-пока

какой веселый неадекват этот Дима АлекееФФ :)

Сначала он показался мне простым неосилятором, но потом я посмотрел его игнор-лист и все понял.

Идея неплохая, но на Qt просто нормально работающий многопоточный tcp-сервер сделать не так просто, не говоря уже об одновременном использовании одной модели по сети множеством клиентов с высокой стабильностью и приемлемой производительностью.

Такие вещи лучше делать на boost::asio, а еще лучше на эрланге.

У вас интересная тема для дискуссии, если оформить её отдельным тредом, я бы с удовольствием пообщался. А пока она существует здесь в виде офтопа, создаётся ощущение, что вам просто хотелось выплеснуть эмоции в виде монолога.

Мы сейчас подумали, что уже несколько раз решали похожие задачи, и наличие обобщенного MVC via network в Qt сильно упростил бы жизнь. Сетевую часть однозначно надо делать на boost, в Qt сетка совсем говно.

Будет свободное время, попробую написать, ТС, спасибо за идею. Только нужно продумать несколько концептуальных моментов, в идеале конечно хотелось бы иметь возможность любую QAbstractItemModel распространять через сеть, наверное идеальным вариантом со стороны сервера будет создавать объект прокси-модели (QNetworkProxyModel), к которой подключается клиент (QNetworkDataModel), они уже сами синхронизируют данные между собой, клиенту даже не надо загружать все данные до их востребования.

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

Мысли хорошие, поддерживаю.

ну опиши на qtproject зареквесть как фичу, помоги с реализацией и будет тебе счастье, а на лоре мы только поулюлююкаем и пальцами потычем

Я с tiago в #qt пообщался сегодня сутра. Он сказал - нафиг нужно. Сейчас планирую просто реализовать это все и дать всем попользоваться. Если народу понравится - буду двигаться в сторону апстрима.

Мы сейчас подумали, что уже несколько раз решали похожие задачи, и наличие обобщенного MVC via network в Qt сильно упростил бы жизнь.

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

QNetworkView это как раз и есть то, что ты назвал QNetworkProxyModel. Но сейчас я уже скорее склоняюсь к взаимодействию через "обезличенный" QIODevice. Прикручивать boost к Qt пока что не вижу смысла. Только если действительно буду упираться в производительность сети в своих задачах.

Сетевую часть однозначно надо делать на boost, в Qt сетка совсем говно.

как «непользователь» boost - что там сделано лучше ? (пара слов)

Залогинься, trex, и перестань дуться.
Думаю что эта тема не настолько важна чтобы из-за неё воевать.

Главное - оно не тормозит. А по API концепция похожая, в бусте регистрируешь хэндлеры для обработки событий (коннект, ввод, вывод и т.д.), в Qt создаешь соответствующии слоты и подключаешь их к сигналам QIODevice. При использовании синхронного I/O разницы так и вообще нет.

Главное - оно не тормозит.

тут подробнее, если можно (глянул бы на тесты, если есть)

У меня нет тестов, но на работе уже многократно проявлялись проблемы, что канал занят на четверть, а проц на всю катушку. Даже банальное

for(;;)
 socket.send(...);

у нас тормозит, хотя в бусте или POSIX напротив, канал забит, а проц на 99% в sleep. Может, Qt загибается на выбросах сигналов или еще что, я не профилировал. А может и руки или карма.

Конечно во многих случаях это может быть некритично, но в данном имхо еще как важно.

qtproject не одним человеком определяется.

у нас тормозит

Если по потоку на сокет, а данных много, то оно и сегфолтиться иногда может, стек вызовов при этом показывает различные глубины Qt.

Ja ne vojuju, i uj virtualov tem bolee ne derju. V kachestve primerenija, ne smotria na to, chto ssoroy daje i ne pahlo, predlagajy sigrat' parteechku v shahmati.

Ok?

Rano s golimi idejami kuda-to lezt'. Vot posle togo, kak vse budet gotovo - mojno budet eshe raz poprobovat'.

Попробую доказать.
Почему не нужно.
Решив сериализацию данных - получается, что нетворк модель как таковая не нужна. Ибо стандартные абстрактные модели покрывают больше чем за глаза. Сериализация, тут на выбор, но если использовать стандартный иодевайс, отпадает возможность прозрачно делать серверную часть на других яп в том числе на пхп, многие не простят. :)
Как стандартный компонент, ну правда не очень нужно, как просто хелпер, возможно нужен.

Если сериализовать и пулять структурировано, предварительно заворачивая в читабельный XML, через QTextStream в иодевайс?

Ну это как раз тот случай, что не нужно, ибо это выродится в простое QTableView.setModel(unserializeToQAbstractItemModel(data)).
Киллер фичи как компонента не вижу. Унифицированный хелпер обмена данными клиент-сервер, тут да.
Хотя... это мое ИМХО конечно. Возможно просто туплю и не понимаю поставленной задачи.

Вы меня с кем-то путаете :)

for(;;) socket.send(...); у нас тормозит

writeData имеет код возврата, поэтому возможно неправильное использование qt, делать при этом выводы не корректно )

writeData имеет код возврата, поэтому возможно неправильное использование qt, делать при этом выводы не корректно )

writeData — protected аж в IODevice, кто из нас его неправильно использует? Или предлагаешь наследоваться от сокета, чтобы «правильно» отправлять им данные? На самом деле я не помнил имени функции, сейчас посмотрел, там не send, а writeDatagram. Жор ядра на 100%, забита треть стомегабитного канала. Нет, я конечно могу взять i7, распараллелить и таки забить сетку, но какой ценой? Выше еще говорят, что при таком раскладе qt иногда может упасть внутрях.

Заметь, writeDatagram — это простейшая «низкоуровневая» функция отправки UDP-пакетов. А я делал на Qt и полноценные TCP и HTTP сервера, по официальным мануалам, с обработкой событий через слоты, т.е. все как положено — оно ОЧЕНЬ тормозит. До смешного доходит, игрушечные сервера на CL работают на порядок или два быстрее.

В общем-то до поры, до времени, мне было насрать на скорость сети в Qt. Но когда обнаружилось, что наши клиенты не могут подключиться к серверам, если на них уже работает десяток человек (обмен данными довольно интенсивный), пришлось быстро что-то решать и решением оказался буст-азио.

если использовать стандартный иодевайс, отпадает возможность прозрачно делать серверную часть на других яп

Матчасть подучите. Никакая возможность тут не отпадает.

Если заведете проект - кинте ссылку на код.