22/06/2007
Цитата:
На мой взгляд это совсем лишнее - ещё и потому, что приглашение и чат системы должен быть УЗНАВАЕМ
На мой взгляд это совсем лишнее - ещё и потому, что приглашение и чат системы должен быть УЗНАВАЕМ
Узнаваемым они должны быть тогда, когда GoTalk будут использовать каждый второй магазин. А каждый второй использовать не будет, так как магазину (если он нормальный магазин) проще самому это все сделать. Либо просто кто-то напишет и будет отдельно продавать. Занедорого. С пояснением как прикрутить. А менеджерская часть будет просто php-скриптом.
22/06/2007
Цитата:
Узнаваемым они должны быть тогда, когда GoTalk будут использовать каждый второй магазин. А каждый второй использовать не будет, так как магазину (если он нормальный магазин) проще самому это все сделать.
Узнаваемым они должны быть тогда, когда GoTalk будут использовать каждый второй магазин. А каждый второй использовать не будет, так как магазину (если он нормальный магазин) проще самому это все сделать.
Сделать аналог - именно с клиентской частью - далеко не проще. Узнаваемость - вопрос времени и раскрутки.
Цитата:
Либо просто кто-то напишет и будет отдельно продавать. Занедорого. С пояснением как прикрутить. А менеджерская часть будет просто php-скриптом.
Либо просто кто-то напишет и будет отдельно продавать. Занедорого. С пояснением как прикрутить. А менеджерская часть будет просто php-скриптом.
Одним php-скриптом тут дело не обойдётся. В данном случае используется достаточно сложный сервер.
Да и магазину проще просто установить код и не заморачиваться с установкой "скриптов".
22/06/2007
Цитата:
Сделать аналог - именно с клиентской частью - далеко не проще
Сделать аналог - именно с клиентской частью - далеко не проще
Да ладно вам. Все состоит из двух php - один клиентский (посетитель к нему запросы), другой менеджера (считайте админка). В БД одна таблица: ид (он же и в куках у посетителя (например md от введеного пользователем e-mail-а)), e-mail, имя (чтобы если что обратиться и так письмо отправить), дата создания (чтобы, например, полугодовой давности чистить), поле - сообщение (разделителем (кто что сказал) например будет ***k*** и ***m***). И все. Нет, не все. Флаг - получил или не получил сообщение. Т.е. выводить при следующем заходе сообщение что есть новое сообщение? Также счетчик кол-ва сообщений модератора. Т.е. модератор ответил, передается пользователю, например, число три. Флаг "получил" ставим в 1. Если сообщение пользователем не получено (по онлоаду срабатывает отправка данных) - то там 1 так и будет, если онлоад произошел (пользователь окно не закрыл) - то тогда устанавливается 0.
При заходе любого пользователя читаем куку, делаем запрос по полю ИД и смотрим что в поле Флаг. Стоит 1 - значит сообщить ему что получен ответ который он еще не читал.
...
Это для одного магазина и так - сходу и на вскидку. Что, магазин так не сделает?
Цитата:
В данном случае используется достаточно сложный сервер.
В данном случае используется достаточно сложный сервер.
Достаточно сложный (а точнее более мощный) сервер по схеме выше понадобится если у вас сервис и подключено тысяча магазинов и от каждого чуть ли не раз в секунду несколько запросов на помощь.
Цитата:
и не заморачиваться с установкой "скриптов".
и не заморачиваться с установкой "скриптов".
Установка скрипта: скопировать и запустить setup.php (либо в PhpMyAdmin выполнить запрос на создание таблицы), вставить на странице html-код.
22/06/2007
> Это для одного магазина и так - сходу и на вскидку. Что, магазин так не сделает?
Для начала подумайте о том, как сообщение от посетителя МГНОВЕННО дойдёт до адресата и оповестит его...
То что вы написали - ерунда.
И клиентская часть получается web - что же теперь, бедному менеджеру постоянно держать открытым браузер и кликать "обновить"?
Скажем так - то что вы написали характерно для мышления web-разработчика, но к сожалению это не подходит для технологий быстрого обмена сообщениями. И естественно ПОДОБНАЯ система уже малоинтересна.
Для начала подумайте о том, как сообщение от посетителя МГНОВЕННО дойдёт до адресата и оповестит его...
То что вы написали - ерунда.
И клиентская часть получается web - что же теперь, бедному менеджеру постоянно держать открытым браузер и кликать "обновить"?
Скажем так - то что вы написали характерно для мышления web-разработчика, но к сожалению это не подходит для технологий быстрого обмена сообщениями. И естественно ПОДОБНАЯ система уже малоинтересна.
22/06/2007
gotalk:
Direct Talk никакого отношения к ICQ не имеет
Direct Talk никакого отношения к ICQ не имеет
А, вы типа из своего готолка в ICQ можете выходить... Ну намутили...
22/06/2007
altsupport:
так как магазину (если он нормальный магазин) проще самому это все сделать
так как магазину (если он нормальный магазин) проще самому это все сделать
В принципе, написать скрипт для подобного мессенджинга в ИМе - пара пустяков... Прикрутить Ajax и делов-то... Не удивлюсь, если в скором времени такие скрипты появятся в свободном доступе
22/06/2007
> В принципе, написать скрипт для подобного мессенджинга в ИМе - пара пустяков...
В общем я уже понял что вы не в теме и вникать не собираетесь - пишите что хотите, флаг в руки,
В общем я уже понял что вы не в теме и вникать не собираетесь - пишите что хотите, флаг в руки,
22/06/2007
gotalk:
В общем я уже понял что вы не в теме и вникать не собираетесь - пишите что хотите, флаг в руки,
В общем я уже понял что вы не в теме и вникать не собираетесь - пишите что хотите, флаг в руки,
Вам интересно наше мнение Вот и мнение - в вашем GoTalk нет ничего такого, за что стоило бы платить деньги, и чего нельзя было бы сделать бесплатно.
Опровергайте
22/06/2007
Цитата:
Для начала подумайте о том, как сообщение от посетителя МГНОВЕННО дойдёт до адресата и оповестит его...
И клиентская часть получается web - что же теперь, бедному менеджеру постоянно держать открытым браузер и кликать "обновить"?
Для начала подумайте о том, как сообщение от посетителя МГНОВЕННО дойдёт до адресата и оповестит его...
И клиентская часть получается web - что же теперь, бедному менеджеру постоянно держать открытым браузер и кликать "обновить"?
Окно можно свернуть.
Руками обновлять не обязательно:
<meta http-equiv="Refresh" content="30" />
Или на Ajax.
А оповестить - промигать окном браузера. А так как браузер может музыку проигрывать - так что и звуком можно.
Можно аж и смс прислать (через маил_ру). Правда выйдет не мгновенно. =)
Цитата:
То что вы написали - ерунда.
Скажем так - то что вы написали характерно для мышления web-разработчика, но к сожалению это не подходит для технологий быстрого обмена сообщениями. И естественно ПОДОБНАЯ система уже малоинтересна.
То что вы написали - ерунда.
Скажем так - то что вы написали характерно для мышления web-разработчика, но к сожалению это не подходит для технологий быстрого обмена сообщениями. И естественно ПОДОБНАЯ система уже малоинтересна.
На огороде где достаточно воткнуть пугало, вы сооружаете инфракрасную систему ПВО с лазерным наведением.
22/06/2007
Цитата:
<meta http-equiv="Refresh" content="30" />
<meta http-equiv="Refresh" content="30" />
Насмешил Через 30 сек, да какой-там... 7 секунд и пользователь гарантировано свалит с сайта И не будет дожидаться вашего ответа.
Поймите, если ограничиваться технологией браузер-php, то даже AJAX не спасёт - нужно иметь возможность пробросить сообщение клиенту мгновенно, сделать popup - чтобы это было удобно, не выжирало трафика килотоннами и не работало "через раз" по той причине, что где-то что-то глюкануло как это обычно бывает в web.
Да и согласитесь - если писать приложение в стиле аджакса - это уже не пхпешные писульки в стиле "база, сообщение туда-то и туда-то"
23/06/2007
gotalk:
Но в вашем случае бесполезно - не поймёте
Но в вашем случае бесполезно - не поймёте
Как Вам угодно
Вас честно пытались предупредить - не стоит возлагать надежды на коммерческую эксплуатацию вашего продукта. Только потратите время и деньги. Бесполезно, - не доходит...
23/06/2007
Цитата:
Вас честно пытались предупредить - не стоит возлагать надежды на коммерческую эксплуатацию вашего продукта
Вас честно пытались предупредить - не стоит возлагать надежды на коммерческую эксплуатацию вашего продукта
buka, да нет, почему, в принципе и может пойти.
Ведь если на основе этого еще и сделать оповещение о заказах. Точнее - не на основе этого, а как дополнение. Имеется в виду оповещение - по мылу, аське, sms. То еще больше можно заинтересовать. Ведь куча народу которые держат ИМ-ы как левый заработок. Но все будет зависеть от расскрученности и от стоимости сервиса.
Цитата:
Через 30 сек, да какой-там... 7 секунд и пользователь.
Через 30 сек, да какой-там... 7 секунд и пользователь.
Можно и семь поставить. И трафика будет не так и много.
Цитата:
сделать popup - чтобы это было удобно
сделать popup - чтобы это было удобно
Значит сделать попап. Ведь тоже можно.
Либо при вопросе еще и дублировать на маил_ру. Все-равно у наших у многих маил_ру_агент стоит. Но возможны задержки.
Либо также на аську извещать. У аськи ведь есть отправка сообщения с веба.
23/06/2007
> Только потратите время и деньги. Бесполезно, - не доходит...
Хорошо, я понял вашу точку зрения.
> Ведь если на основе этого еще и сделать оповещение о заказах.
Нет, мне кажется это не совсем то, что нужно.
Система оповещения о заказах должна быть встроена в логику ИМ. А тут она просто не при делах - всё-таки чат с посетителем не может быть инициирован в любое время.
> Можно и семь поставить. И трафика будет не так и много.
Можете сами попробовать, но я вас уверяю - это буде ОЧЕНЬ коряво. Вебу просто не хватит интерактивности чтобы покрыть этот функционал, уж не говоря про иконку в трее и быстрый отклик.
А если ещё и дублировать на mail.ru - это будет просто МЯСО.
И что самое важное - сложность такой системы будет намного выше, чем у Direct Talk.
> Либо также на аську извещать. У аськи ведь есть отправка сообщения с веба.
Аська это вобще больной вопрос. Уж поверьте - имея на руках icq-бот и icq-шлюз с собственной реализацией icq-протокола мы поимели очень много геммороя и знаем что это такое...
Ведь изначально именно icq-шлюз планировался для этих целей, но качество его работы на участке icq оставляет желать лучшего...
Естественно Direct Talk - самодостаточное приложение.
Почему он идёт как сервис - потому что мы обеспечиваем и гарантируем его бесперебойную работу.
Хорошо, я понял вашу точку зрения.
> Ведь если на основе этого еще и сделать оповещение о заказах.
Нет, мне кажется это не совсем то, что нужно.
Система оповещения о заказах должна быть встроена в логику ИМ. А тут она просто не при делах - всё-таки чат с посетителем не может быть инициирован в любое время.
> Можно и семь поставить. И трафика будет не так и много.
Можете сами попробовать, но я вас уверяю - это буде ОЧЕНЬ коряво. Вебу просто не хватит интерактивности чтобы покрыть этот функционал, уж не говоря про иконку в трее и быстрый отклик.
А если ещё и дублировать на mail.ru - это будет просто МЯСО.
И что самое важное - сложность такой системы будет намного выше, чем у Direct Talk.
> Либо также на аську извещать. У аськи ведь есть отправка сообщения с веба.
Аська это вобще больной вопрос. Уж поверьте - имея на руках icq-бот и icq-шлюз с собственной реализацией icq-протокола мы поимели очень много геммороя и знаем что это такое...
Ведь изначально именно icq-шлюз планировался для этих целей, но качество его работы на участке icq оставляет желать лучшего...
Естественно Direct Talk - самодостаточное приложение.
Почему он идёт как сервис - потому что мы обеспечиваем и гарантируем его бесперебойную работу.
Ответить