Amber, Pharo and Seaside

Тема заслуживает отдельной ветки.

28 января 2015 г., 21:04 пользователь Nikolay Kleptsov <[hidden email]> написал:

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

Никак не могу найти время подтвердить (или внезапно опровергнуть?) примерно такой тезис:

Seaside реализует подход, не соображу сейчас, как его правильно обозначить… Ну, в общем, с упором на сервер… Многостраничный что ли? Есть люди которые утверждают, что данный подход стремительно устаревает или даже уже устарел.

Amber — представитель другого подхода, когда клиент очень толстый, одно окно… И браузер — операционка. Типа подход сегодняшнего дня и обозримого будущего. Amber + Pharo по некому протоколу поверх WebSocket-а здесь будет очень кстати.

Материал по теме: http://www.confreaks.com/videos/359-gogaruco2010-rails-is-obsolete-but-so-s-everything-else (обратите внимание на авторство).

А вот "смешивать" Seaside и Amber не вижу причин — они не дополняют, а противоречат друг другу. 

Жду подтверждений/опровержений.

--

Best regards,

Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

не обязательно Seaside с Amber объединять. На стороне Pharo добавить компилятор Amber, который генерирует js код

29 января 2015 г., 9:02 пользователь Dennis Schetinin <[hidden email]> написал:

Тема заслуживает отдельной ветки.

28 января 2015 г., 21:04 пользователь Nikolay Kleptsov <[hidden email]> написал:

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

Никак не могу найти время подтвердить (или внезапно опровергнуть?) примерно такой тезис:

Seaside реализует подход, не соображу сейчас, как его правильно обозначить… Ну, в общем, с упором на сервер… Многостраничный что ли? Есть люди которые утверждают, что данный подход стремительно устаревает или даже уже устарел.

Amber — представитель другого подхода, когда клиент очень толстый, одно окно… И браузер — операционка. Типа подход сегодняшнего дня и обозримого будущего. Amber + Pharo по некому протоколу поверх WebSocket-а здесь будет очень кстати.

Материал по теме: http://www.confreaks.com/videos/359-gogaruco2010-rails-is-obsolete-but-so-s-everything-else (обратите внимание на авторство).

А вот "смешивать" Seaside и Amber не вижу причин — они не дополняют, а противоречат друг другу. 

Жду подтверждений/опровержений.

--

Best regards,

Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Amber — представитель другого подхода, когда клиент очень толстый, одно окно… И браузер — операционка. Типа подход сегодняшнего дня и обозримого будущего. Amber + Pharo по некому протоколу поверх WebSocket-а здесь будет очень кстати.

И да и нет.

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

Подход 90 годов, до массового распространения JS приложений:

- Браузер это интерфейс между пользователем и приложением на сервере. Задача браузера - сбор информации от пользователя (клики/формы) и отправка их на сторону сервера. Сервер целиком и полностью определяет, как будут обработаны данные и что будет показано пользователю, посколько он отдает по запросам браузера html

Подход современных JS приложений:

- Что и как отображается определяется JS приложением на клиентской стороне. JS-приложение в браузере запрашивает у сервера какие-либо данные, которые возвращаются, как правило, в формате JSON и использую их, рендерит html. Фактически, сервер нужен только для обслуживания статических страниц и как интерфейс между хранилищем данных.

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

Пытаться скрещивать seaside и JS-приложение? И что будет? JS-приложение получает сгенеренные целиком страницы html c сервера и показывает пользователю? Нафига тогда JS приложение вообще нужно?

Получать куски html с сервера и встраивать их в DOM дерево у клиента? Шизофрения у разработчика обеспечена - пытаться удержать в голове, что у нас тут на сервере рендерится, а что на стороне клиента.

Да и какой профит от этого? Выигрышей в скорости не будет, современные JS engine, тот же V8 достаточно шустро, чтобы что-то отрендерить на клиенте было быстрее, чем устанавливать http-соединение с сервером

Я могу ошибаться и предлагается какой-то другой подход? Опишите подробнее, кто хорошо себе это представляет, пожалуйста? 

Ну а Pharo может выступать для amber, как поставщик данных, так же как и любой другой серверный бэкхенд написанный на C++/ruby/perl/php/java/здесь_ваш_любимый_язык_программирования

Отдельным интересом может служить реализация чего-то типа Opentalk от Cincom VW. Когда на клиенте можно получить доступ к северным объектам. Например, сервер выставляет наружу доступ к Transcript,

а на клиенте мы пишем что-то типа: 

serverTranscript := Server.getEnvironment[’Transcript’].

serverTranscript.crShow: ‘Hello from client’ 

и видим в серверном Transcript это сообщение.

Возможно, вы это имеете ввиду?

Материал по теме: http://www.confreaks.com/videos/359-gogaruco2010-rails-is-obsolete-but-so-s-everything-else (обратите внимание на авторство).

А вот "смешивать" Seaside и Amber не вижу причин — они не дополняют, а противоречат друг другу. 

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Amber — представитель другого подхода, когда клиент очень толстый, одно окно… И браузер — операционка. Типа подход сегодняшнего дня и обозримого будущего. Amber + Pharo по некому протоколу поверх WebSocket-а здесь будет очень кстати.

И да и нет.

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

Подход 90 годов, до массового распространения JS приложений:

- Браузер это интерфейс между пользователем и приложением на сервере. Задача браузера - сбор информации от пользователя (клики/формы) и отправка их на сторону сервера. Сервер целиком и полностью определяет, как будут обработаны данные и что будет показано пользователю, посколько он отдает по запросам браузера html

Подход современных JS приложений:

- Что и как отображается определяется JS приложением на клиентской стороне. JS-приложение в браузере запрашивает у сервера какие-либо данные, которые возвращаются, как правило, в формате JSON и использую их, рендерит html. Фактически, сервер нужен только для обслуживания статических страниц и как интерфейс между хранилищем данных.

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

Пытаться скрещивать seaside и JS-приложение? И что будет? JS-приложение получает сгенеренные целиком страницы html c сервера и показывает пользователю? Нафига тогда JS приложение вообще нужно?

Получать куски html с сервера и встраивать их в DOM дерево у клиента? Шизофрения у разработчика обеспечена - пытаться удержать в голове, что у нас тут на сервере рендерится, а что на стороне клиента.

Да и какой профит от этого? Выигрышей в скорости не будет, современные JS engine, тот же V8 достаточно шустро, чтобы что-то отрендерить на клиенте было быстрее, чем устанавливать http-соединение с сервером

Я могу ошибаться и предлагается какой-то другой подход? Опишите подробнее, кто хорошо себе это представляет, пожалуйста? 

Ну а Pharo может выступать для amber, как поставщик данных, так же как и любой другой серверный бэкхенд написанный на C++/ruby/perl/php/java/здесь_ваш_любимый_язык_программирования

Отдельным интересом может служить реализация чего-то типа Opentalk от Cincom VW. Когда на клиенте можно получить доступ к северным объектам. Например, сервер выставляет наружу доступ к Transcript,

а на клиенте мы пишем что-то типа: 

serverTranscript := Server.getEnvironment[’Transcript’].

serverTranscript.crShow: ‘Hello from client’ 

и видим в серверном Transcript это сообщение.

Возможно, вы это имеете ввиду?

Материал по теме: http://www.confreaks.com/videos/359-gogaruco2010-rails-is-obsolete-but-so-s-everything-else (обратите внимание на авторство).

А вот "смешивать" Seaside и Amber не вижу причин — они не дополняют, а противоречат друг другу. 

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Ну, возможно, с академической т.з. всё красиво и не требует никаких «неправильных» подходов и манипуляций.

На практике же, почему-то, шибко хочется скрестить ужа с ежом... ;)

или даже так: «заменить ежа на ёжеподобного ужа» О_о

Спорить не буду (некоторые аспекты которые напрягают уже описаны, но видимо они не считаются серьёзными) наверное самое простое когда ниб попробовать реализовать хотя бы в общих чертах что я имел ввиду

PS. работать со смолток кодом амбера в фаро и соответствено хранить его в монтичело это был бы уже большой плюс (от амбера по сути нужен тогда только его компилятор)

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Случаи бывают разные, но в данном случае я не понимаю этого желания.

От амбера же будет требоваться еще возможность соединиться с Pharo, загружать по сети код по его запросу, выполнять, отправлять обратно результат. Короче, нужно реализовать OpenTalk — здесь мои мысли до мурашек сходятся со сказанным Владимиром. Только в моих фантазиях этот протокол сам по себе — это не данные, кодирующие что-то там, а реальный Smalltalk-код (или может быть даже "очищенный Smalltalk"). 

--

Best regards,

Dennis Schetinin

29 января 2015 г., 12:11 пользователь Ремизов Александр <[hidden email]> написал:

Ну, возможно, с академической т.з. всё красиво и не требует никаких «неправильных» подходов и манипуляций.

На практике же, почему-то, шибко хочется скрестить ужа с ежом... ;)

или даже так: «заменить ежа на ёжеподобного ужа» О_о

Спорить не буду (некоторые аспекты которые напрягают уже описаны, но видимо они не считаются серьёзными) наверное самое простое когда ниб попробовать реализовать хотя бы в общих чертах что я имел ввиду

PS. работать со смолток кодом амбера в фаро и соответствено хранить его в монтичело это был бы уже большой плюс (от амбера по сути нужен тогда только его компилятор)

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

У меня есть одна реализация OpenTalk клиентская часть сделана в Eight, серверная на основе Tide.

29 января 2015 г., 14:33 пользователь Dennis Schetinin <[hidden email]> написал:

Случаи бывают разные, но в данном случае я не понимаю этого желания.

От амбера же будет требоваться еще возможность соединиться с Pharo, загружать по сети код по его запросу, выполнять, отправлять обратно результат. Короче, нужно реализовать OpenTalk — здесь мои мысли до мурашек сходятся со сказанным Владимиром. Только в моих фантазиях этот протокол сам по себе — это не данные, кодирующие что-то там, а реальный Smalltalk-код (или может быть даже "очищенный Smalltalk"). 

--

Best regards,

Dennis Schetinin

29 января 2015 г., 12:11 пользователь Ремизов Александр <[hidden email]> написал:

Ну, возможно, с академической т.з. всё красиво и не требует никаких «неправильных» подходов и манипуляций.

На практике же, почему-то, шибко хочется скрестить ужа с ежом... ;)

или даже так: «заменить ежа на ёжеподобного ужа» О_о

Спорить не буду (некоторые аспекты которые напрягают уже описаны, но видимо они не считаются серьёзными) наверное самое простое когда ниб попробовать реализовать хотя бы в общих чертах что я имел ввиду

PS. работать со смолток кодом амбера в фаро и соответствено хранить его в монтичело это был бы уже большой плюс (от амбера по сути нужен тогда только его компилятор)

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Полноценная реализация OpenTalk? Можно чуть подробнее?

--

Best regards,

Dennis Schetinin

29 января 2015 г., 12:48 пользователь Nikolay Kleptsov <[hidden email]> написал:

У меня есть одна реализация OpenTalk клиентская часть сделана в Eight, серверная на основе Tide.

29 января 2015 г., 14:33 пользователь Dennis Schetinin <[hidden email]> написал:

Случаи бывают разные, но в данном случае я не понимаю этого желания.

От амбера же будет требоваться еще возможность соединиться с Pharo, загружать по сети код по его запросу, выполнять, отправлять обратно результат. Короче, нужно реализовать OpenTalk — здесь мои мысли до мурашек сходятся со сказанным Владимиром. Только в моих фантазиях этот протокол сам по себе — это не данные, кодирующие что-то там, а реальный Smalltalk-код (или может быть даже "очищенный Smalltalk"). 

--

Best regards,

Dennis Schetinin

29 января 2015 г., 12:11 пользователь Ремизов Александр <[hidden email]> написал:

Ну, возможно, с академической т.з. всё красиво и не требует никаких «неправильных» подходов и манипуляций.

На практике же, почему-то, шибко хочется скрестить ужа с ежом... ;)

или даже так: «заменить ежа на ёжеподобного ужа» О_о

Спорить не буду (некоторые аспекты которые напрягают уже описаны, но видимо они не считаются серьёзными) наверное самое простое когда ниб попробовать реализовать хотя бы в общих чертах что я имел ввиду

PS. работать со смолток кодом амбера в фаро и соответствено хранить его в монтичело это был бы уже большой плюс (от амбера по сути нужен тогда только его компилятор)

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Ну, это не совсем еще OpenTalk, наверное —  только самая основа? Но все равно штука полезная. В любом случае, буду иметь ввиду.  http://smalltalkhub.com/#!/~Kleptsov/Eight — вижу, а остальное доступно? Или http://smalltalkhub.com/#!/~Kleptsov/AssemblyWorkshop — оно и будет?

Кстати, упаковку/распаковку другую можно подсунуть?

…И еще хочу спросить, используется где-то?

--

Best regards,

Dennis Schetinin

29 января 2015 г., 13:07 пользователь Nikolay Kleptsov <[hidden email]> написал:

Eight может упаковывать объекты в BSON формат и распаковывать.

На стороне клиента объект упаковывается (aMessageSend)
далее через веб протокол передается серверу.
На сервере из BSON восстанавливается объект (aMessageSend), посылается сообщение
Результат упакавывается в BSON и в качестве ответа возвращается.

Клиент востанавливает объект.

29 января 2015 г., 14:56 пользователь Dennis Schetinin <[hidden email]> написал:

Полноценная реализация OpenTalk? Можно чуть подробнее?

--

Best regards,

Dennis Schetinin

29 января 2015 г., 12:48 пользователь Nikolay Kleptsov <[hidden email]> написал:

У меня есть одна реализация OpenTalk клиентская часть сделана в Eight, серверная на основе Tide.

29 января 2015 г., 14:33 пользователь Dennis Schetinin <[hidden email]> написал:

Случаи бывают разные, но в данном случае я не понимаю этого желания.

От амбера же будет требоваться еще возможность соединиться с Pharo, загружать по сети код по его запросу, выполнять, отправлять обратно результат. Короче, нужно реализовать OpenTalk — здесь мои мысли до мурашек сходятся со сказанным Владимиром. Только в моих фантазиях этот протокол сам по себе — это не данные, кодирующие что-то там, а реальный Smalltalk-код (или может быть даже "очищенный Smalltalk"). 

--

Best regards,

Dennis Schetinin

29 января 2015 г., 12:11 пользователь Ремизов Александр <[hidden email]> написал:

Ну, возможно, с академической т.з. всё красиво и не требует никаких «неправильных» подходов и манипуляций.

На практике же, почему-то, шибко хочется скрестить ужа с ежом... ;)

или даже так: «заменить ежа на ёжеподобного ужа» О_о

Спорить не буду (некоторые аспекты которые напрягают уже описаны, но видимо они не считаются серьёзными) наверное самое простое когда ниб попробовать реализовать хотя бы в общих чертах что я имел ввиду

PS. работать со смолток кодом амбера в фаро и соответствено хранить его в монтичело это был бы уже большой плюс (от амбера по сути нужен тогда только его компилятор)

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

В Eight перед сохранением объектов в базу упаковываются в json подобный словарь. Это свойство Eight и используется для передачи сообщений на сервер, только упакованный объект не сохраняется в базе, а посылается на сервер.

Когда возникла необходимость получать объекты от удаленной Фаро, воспользовался "побочным" свойтвом Eight. Упакованные объекты можно распознавать и не в Smalltalk системах, конечно полная функциональность будет в Pharo, но отбросив поведение объектов можно передавать данные даже в браузеры.

Используется в проекте ELearning Editor

29 января 2015 г., 15:41 пользователь Dennis Schetinin <[hidden email]> написал:

Ну, это не совсем еще OpenTalk, наверное —  только самая основа? Но все равно штука полезная. В любом случае, буду иметь ввиду.  http://smalltalkhub.com/#!/~Kleptsov/Eight — вижу, а остальное доступно? Или http://smalltalkhub.com/#!/~Kleptsov/AssemblyWorkshop — оно и будет?

Кстати, упаковку/распаковку другую можно подсунуть?

…И еще хочу спросить, используется где-то?

--

Best regards,

Dennis Schetinin

29 января 2015 г., 13:07 пользователь Nikolay Kleptsov <[hidden email]> написал:

Eight может упаковывать объекты в BSON формат и распаковывать.

На стороне клиента объект упаковывается (aMessageSend)
далее через веб протокол передается серверу.
На сервере из BSON восстанавливается объект (aMessageSend), посылается сообщение
Результат упакавывается в BSON и в качестве ответа возвращается.

Клиент востанавливает объект.

29 января 2015 г., 14:56 пользователь Dennis Schetinin <[hidden email]> написал:

Полноценная реализация OpenTalk? Можно чуть подробнее?

--

Best regards,

Dennis Schetinin

29 января 2015 г., 12:48 пользователь Nikolay Kleptsov <[hidden email]> написал:

У меня есть одна реализация OpenTalk клиентская часть сделана в Eight, серверная на основе Tide.

29 января 2015 г., 14:33 пользователь Dennis Schetinin <[hidden email]> написал:

Случаи бывают разные, но в данном случае я не понимаю этого желания.

От амбера же будет требоваться еще возможность соединиться с Pharo, загружать по сети код по его запросу, выполнять, отправлять обратно результат. Короче, нужно реализовать OpenTalk — здесь мои мысли до мурашек сходятся со сказанным Владимиром. Только в моих фантазиях этот протокол сам по себе — это не данные, кодирующие что-то там, а реальный Smalltalk-код (или может быть даже "очищенный Smalltalk"). 

--

Best regards,

Dennis Schetinin

29 января 2015 г., 12:11 пользователь Ремизов Александр <[hidden email]> написал:

Ну, возможно, с академической т.з. всё красиво и не требует никаких «неправильных» подходов и манипуляций.

На практике же, почему-то, шибко хочется скрестить ужа с ежом... ;)

или даже так: «заменить ежа на ёжеподобного ужа» О_о

Спорить не буду (некоторые аспекты которые напрягают уже описаны, но видимо они не считаются серьёзными) наверное самое простое когда ниб попробовать реализовать хотя бы в общих чертах что я имел ввиду

PS. работать со смолток кодом амбера в фаро и соответствено хранить его в монтичело это был бы уже большой плюс (от амбера по сути нужен тогда только его компилятор)

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.