Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Mr.Cat, вы писали:

MC>> А если клиент отсоединится? У меня вот, бывает, роутер заглючит, вайфай нечаянно выключу или еще чего — куда контекст денется?
S>Чудес не бывает, хотя в этом направлении Олег тоже работал. Я не знаю как сейчас, но когда я писал под ведгу — обрыв связи был критичен. Впрочем он критичен практически везде.

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

Приветствую, kochetkov.vladimir, вы писали:

k> S>Ведга вообще держит отдельный поток (или форк. Раньше были форки, но автор говорил что переводит нав потоки) на каждого клиента.

k> Что мне мешает с 10 рабочих станций инициировать 100 тысяч клиентских соединений на сервер ведги? Что произойдет в этом случае?
Гм. Будет подтормаживать скорее всего. Серебряной пули нет.
Вот вы интересные... А если я в серверной mail.ru тонну динамита взорву — mail.ru работать будет?

M>> S>Мамут. Твой софт — дерьмо. Я его правда не видет и ине трогал. Но он — дерьмо. Пока не докажешь обратное.
M>> S>Приятно?
M>> S>Вот приблизительно это ты и заявляешь со всей прямотой.

M>> Так и есть. Понимаешь, именно так и работает индустрия. И я к этому спокойно отношусь, в отличие от. Ценность и полезность каких-либо решений надо доказывать. Причем доказывать убедительно.

S>Мамут, мы нихера не конкуренты, так что меня можно и не обливать дерьмом.

А причем тут конкуренты-не конкуренты?

S>В двух словах: некий заказчик обещает забрать у него все, вместе с ведгой, лишив авторских и прочих прав итд.

Хм. Странная ситуация. Такое может быть только если сама ведга была написана по заказу этого заказчика Но такое тоже вполне может быть

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, kochetkov.vladimir, вы писали:

k>> S>Ведга вообще держит отдельный поток (или форк. Раньше были форки, но автор говорил что переводит нав потоки) на каждого клиента.

k>> Что мне мешает с 10 рабочих станций инициировать 100 тысяч клиентских соединений на сервер ведги? Что произойдет в этом случае?
S>Гм. Будет подтормаживать скорее всего. Серебряной пули нет.

Признайся честно — из какой вселенной вы пришли чтобы захавать нашу Землю? В каком измерении ОС, поддерживающая работу 100 тысяч одновременных потоков, активно работающих с сетью на каждый чих любой из 100 тысяч клиентских систем, будет "подтормаживать"?

S>Вот вы интересные... А если я в серверной mail.ru тонну динамита взорву — mail.ru работать будет?

Я не знаю, чем тебе не угодил mail.ru, но если ты это сделаешь у нас (в конторе, в датацентре МСК), то в столице пропадет наша сотовая связь примерно на 2-3 минуты, а регионах этого не ощутят вообще

g>>> S>Напоминаю что в случае ведга-приложения контекст клиента сервер никогда не теряет.
g>>> То есть держит открытое соединение, что очень плохо в плане расходования ресурсов.
S>>Поподробнее.
G>Держать открытие сокеты — небесплатно. Кроме того при поддержке постянного соединения нет возможности балансировки нагрузки.

G>Кроме самого сокета удерживается еще все состояние интерфейса, которое и так присуствует на клиенте.

Там еще дополнительно хуже. На каждого нового клиента к этому же приложению делается fork всего приложения.

Здравствуйте, gandjustas, Вы писали:

H>>Я не специалист по 1C. Никогда не писал под нее и надеюсь не придется. Но не думаю, что какой нибудь "касса\приход\3465" трудно распарсить и спозиционировать приложение.

G>Ну распарсить — полбеды. А вот что значит "спозиционировать приложение" ? А история навигации будет? Как она будет работать?
G>А что будет если я введу данные, а потом перейду по ссылке, не сохранив ничего и вернусь назад?

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

G>Можешь почитать как работает навигация в WPF, там множество тонких моментов возникает.

Зачем мне навигая ради навигации

G>>>Ждать что заказчик тебе скажет про адресуемость не стоит, зачастую это вопрос юзабилити, а не функциональных требований.
H>>Вопросы юзабилити обсуждаются на этапе согласования интерфейса с заказчиком
G>Ну если нарисуете инерфейс с навигацией, то заказчик согласует такой. Без навигации — тоже согласует.

Пардон, тут адресуемость называют чуть ли не обязательной фичей. При таком раскладе заказчик вряд ли забудет на это указать.

Здравствуйте, hattab, Вы писали:


G>>>>Ждать что заказчик тебе скажет про адресуемость не стоит, зачастую это вопрос юзабилити, а не функциональных требований.
H>>>Вопросы юзабилити обсуждаются на этапе согласования интерфейса с заказчиком
G>>Ну если нарисуете инерфейс с навигацией, то заказчик согласует такой. Без навигации — тоже согласует.

H>Пардон, тут адресуемость называют чуть ли не обязательной фичей. При таком раскладе заказчик вряд ли забудет на это указать.
Еще раз. Навигация больше касается юзабилити. заказчики зачастую не могут все функциональные требования описать, не что нефункциональные (к которым юзабилити и относится).

Приветствую, Mamut, вы писали:

M> S>В двух словах: некий заказчик обещает забрать у него все, вместе с ведгой, лишив авторских и прочих прав итд.
M> Хм. Странная ситуация. Такое может быть только если сама ведга была написана по заказу этого заказчика Но такое тоже вполне может быть
Нет, ведга разрабатывалась Олегом. Он ее задумал и начал писать еще во времена 3го кутэ.

Приветствую, kochetkov.vladimir, вы писали:

k> S>Гм. Будет подтормаживать скорее всего. Серебряной пули нет.

k> Признайся честно — из какой вселенной вы пришли чтобы захавать нашу Землю? В каком измерении ОС, поддерживающая работу 100 тысяч одновременных потоков, активно работающих с сетью на каждый чих любой из 100 тысяч клиентских систем, будет "подтормаживать"?
Ты просто не указал на каком серванте это дело поднято будет и какого типа приложение

Здравствуйте, gandjustas, Вы писали:

H>>Пардон, тут адресуемость называют чуть ли не обязательной фичей. При таком раскладе заказчик вряд ли забудет на это указать.
G>Еще раз. Навигация больше касается юзабилити. заказчики зачастую не могут все функциональные требования описать, не что нефункциональные (к которым юзабилити и относится).

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

M>> S>В двух словах: некий заказчик обещает забрать у него все, вместе с ведгой, лишив авторских и прочих прав итд.
M>> Хм. Странная ситуация. Такое может быть только если сама ведга была написана по заказу этого заказчика Но такое тоже вполне может быть
S>Нет, ведга разрабатывалась Олегом. Он ее задумал и начал писать еще во времена 3го кутэ.

Тогда не понимаю, кто и как может забрать все, вместе с ведгой и лишить авторских прав

Приветствую, Mamut, вы писали:

M> Тогда не понимаю, кто и как может забрать все, вместе с ведгой и лишить авторских прав

Это Россия, друг....
Посмотри наконец видео.

k>> S>Гм. Будет подтормаживать скорее всего. Серебряной пули нет.

k>> Признайся честно — из какой вселенной вы пришли чтобы захавать нашу Землю? В каком измерении ОС, поддерживающая работу 100 тысяч одновременных потоков, активно работающих с сетью на каждый чих любой из 100 тысяч клиентских систем, будет "подтормаживать"?
S>Ты просто не указал на каком серванте это дело поднято будет и какого типа приложение

100 тыс. клиентов. 20 байт на каждое телодвижение мышки.

100 000 * 20 = 2 000 000 байт = 16 000 000 bit = 15 Mbit. На каждое движение мышки в этих клиентах. И ведь load balancing нормально не сделаешь.

Приветствую, Mamut, вы писали:

M> k>> S>Гм. Будет подтормаживать скорее всего. Серебряной пули нет.

M> k>> Признайся честно — из какой вселенной вы пришли чтобы захавать нашу Землю? В каком измерении ОС, поддерживающая работу 100 тысяч одновременных потоков, активно работающих с сетью на каждый чих любой из 100 тысяч клиентских систем, будет "подтормаживать"?

M> S>Ты просто не указал на каком серванте это дело поднято будет и какого типа приложение

M> 100 тыс. клиентов. 20 байт на каждое телодвижение мышки.
Неверно. Впрочем можно конечно каждое телоджвижение мыша на сервер отправлять, но зачем?
По сети ходят только сигналы от контролов, интерфейс и данные. Тоесть движение мыша не отправляется. Отправляется к примеру клик по кнопке (десятки байт), да и то, если сигнал прописан.

M> 100 000 * 20 = 2 000 000 байт = 16 000 000 bit = 15 Mbit. На каждое движение мышки в этих клиентах. И ведь load balancing нормально не сделаешь.
Неверный вывод основанный на неверном предположении.

M>> 100 тыс. клиентов. 20 байт на каждое телодвижение мышки.
S>Неверно. Впрочем можно конечно каждое телоджвижение мыша на сервер отправлять, но зачем?
S>По сети ходят только сигналы от контролов, интерфейс и данные. Тоесть движение мыша не отправляется. Отправляется к примеру клик по кнопке (десятки байт), да и то, если сигнал прописан.

M>> 100 000 * 20 = 2 000 000 байт = 16 000 000 bit = 15 Mbit. На каждое движение мышки в этих клиентах. И ведь load balancing нормально не сделаешь.
S>Неверный вывод основанный на неверном предположении.

Одно (два?) слово: drag and drop

Здравствуйте, Mamut, Вы писали:

M> 100 тыс. клиентов.

Не получится на одном IP с постоянными соединениями.

Приветствую, Anton Batenev, вы писали:

AB> M> 100 тыс. клиентов.
AB> Не получится на одном IP с постоянными соединениями.
Ну у нас процессор в памяти

Автор: Sheridan
Дата: 27.11.09

, нам все можно.

Здравствуйте, Sheridan, Вы писали:

S> AB> M> 100 тыс. клиентов.
S> AB> Не получится на одном IP с постоянными соединениями.
S> Ну у нас процессор в памяти

Автор: Sheridan
Дата: 27.11.09

, нам все можно.

А это к процессору не имеет отношения

Здравствуйте, Mr.Cat, Вы писали:

S>>Впрочем он критичен практически везде.
MC>При работе через ремут-десктоп — нет. Разорвалось соединение — пофиг. Восстановил, залогинился, продолжил работать. С простым html — аналогично — все состояние — в куках, строке адреса, на сервере — обычно достаточно обновить страничку после восстановления коннекта.

Никогда не видел на форумах посты по три раза? Всего лишь обрыв связи. А казалось бы — hhtp к нему устойчив...

MC>С ajax/flex/silverlight — момент коннекта к серверу явно прописан — ошибку коннекта можно обработать в коде.

Вообще при некоторых моделях построения приложения эти вопросы может и библиотека порешать. Тупо спросить пользователя например — уже забъём или попробуем еще разок пересоединиться.

S>>...в этом направлении Олег тоже работал
S>>Я знаю лишь что какието изменения были.
MC>Вот-вот. Что-то делалось, а что — непонятно.

Да вообще в толстых клиентах проблема с дропаньем контекста пользователя на стороне сервера вроде как не особо сложно решается. Явно отсоединился — бросаем контекст сразу, отвалился с ошибкой/просто не дает о себе знать — ждем какое-то время (время можно выбирать адаптивно, в зависимости от нагрузки). И ничего принципиально лучшего по-моему и не придумаешь...