ax3,ax4,ax2009,ax2012: Есть ли красивый способ передать packable объект между клиентом и сервером?

[gl00mie]

Цитата:

Сообщение от mazzy

Что именно "все" уже реализовано в RunBase?

Вот это вот всё:

Цитата:

Сообщение от mazzy

Сейчас, чтобы передать объект с клиента на сервер и обратно, приходится подпрыгивать с методами newOnServer, newOnClient, вручную проверять ObjectOnServer, вызывать pack/unpack и прочие некрасивости.

В RunBase уже есть запуск на сервере, переключение на клиента, вызовы pack/unpack и даже подсказка, вызываются ли они внутри диалога или нет.

Цитата:

Сообщение от mazzy

Цитата:

Сообщение от gl00mie

Что за сценарий использования, если не секрет?

Как изменится ответ на исходный вопрос?

Я начну издалека Есть целый ряд людей, которые задают очень и очень общие вопросы или весьма "широко" формулируют задачу, имея в виду весьма конкретный частный случай. Этим любят заниматься и разработчики, и консультанты, и пользователи. Но когда начинаешь задавать уточняющие вопросы, часто оказывается, что их частный случай, который они имеют в виду, формулируя общую проблему, имеет с этой формулировкой не так уж много общего.
Таким образом, ответ на исходный вопрос может кардинально отличаться в зависимости от того, о какой конкретной задаче исходно идет речь. Банально, потому что постановка задачи

Цитата:

Сообщение от mazzy

красивый способ передать packable объект между клиентом и сервером

в моем понимании очень отличается от постановки задачи

Цитата:

Сообщение от mazzy

передать объект с клиента на сервер и обратно

Я, к примеру, не понимаю сходу, зачем один и тот же packable объект передавать обратно с сервера на клиента, если это что-то, выходящее за рамки возможностей, уже реализованных в RunBase. Импортированный файл передать на сервер и потом обратно или что? И если надо все же передавать данные в обе стороны, то точно ли это будет один и тот же packable объект?

Даже если речь про сферический packable объект в вакууме, и стоит задача разработки некоего универсального фреймворка для благодарных потомков, то и тогда не помешало бы озвучить сценарии использования, на которые фреймворк будет рассчитан.