Есть некая задача, которую по всем прикидкам удобнее всего было бы решить в виде web-приложения. некое сетевое приложение, в котором будут работать филиалы нашей компании.
Проблема в том, что на определенном этапе нуно обратиться к специфическому железу у клиента на компе. собственно насколько я понимаю варианта решения два:
1) забить на браузер, поставить всем приложение, состоящее буквально из одной формы, на которую кинут WebBrowser. ПОнятно что из своего приложения мы можем обобщатся с железом как хотим.
не нравится то, что приложение будет не совсем простым, нуно будет повторить функциональность браузера. а повторять то что уже написано — не не нравится.
2) писать плагин для браузера.
вообще не представляю как это все делает. есть ли какой нить единый стандарт на это?? тот же flash вроде под все браузеры есть.
> Проблема в том, что на определенном этапе нуно обратиться к > специфическому железу у клиента на компе.
Если железо это принтер, то браузеры отлично с ним работают
Если устройства аудио и/или видеозахвата, то флеш может с ними работать.
Если же что-то совсем другое, то придется прыгать.
ИМХО лучше всего сделать простенькую программку. Запускаешь, она
подключается к железу и к веб серверу. Все что делает железо — отсылает
веб серверу. Также команды от веб сервера посылает на железо. На веб
сервере вести список активных моделей этих железок, по количеству
запущенных "простеньких приложений" и все что делается в вебе, делать с
вышеупомянутыми моделями.
Здравствуйте, Other Sam, Вы писали:
>> Проблема в том, что на определенном этапе нуно обратиться к >> специфическому железу у клиента на компе.
OS>Если железо это принтер, то браузеры отлично с ним работают OS>Если устройства аудио и/или видеозахвата, то флеш может с ними работать. OS>Если же что-то совсем другое, то придется прыгать.
железо — специфическое. электронные ключи.
OS>ИМХО лучше всего сделать простенькую программку. Запускаешь, она OS>подключается к железу и к веб серверу. Все что делает железо — отсылает OS>веб серверу. Также команды от веб сервера посылает на железо.
ну то есть вариант один.
а чем плагин к браузерам плох??
> ну то есть вариант один. > а чем плагин к браузерам плох??
Нет, не один. Это мое личное мнение. При таком подходе довольно удобно
развивать и поддерживать систему. Плагин к браузеру тоже подойдет, но
при этом либо своих пользователей ограничите в выборе операционной
системы и браузера, либо будете поддерживать несколько плагинов для
разных систем и браузеров.
Что касается электронных ключей, тут все не так однозначно. Ключи
используются для контроля использования специального софта на конкретной
вычислительной машине. Т.е. некий софт работает на железе только в
случае, если в составе железа есть специальное устройство — собственно
ключ. На клиентской машине используется браузер, чтобы ограничить его
работу придется создавать собственный браузер.
Короче нужно больше информации. Что делает ключ, для чего, и как это
должно отражаться на работе веб приложения?
Здравствуйте, Other Sam, Вы писали:
>> ну то есть вариант один. >> а чем плагин к браузерам плох??
OS>Нет, не один. Это мое личное мнение. При таком подходе довольно удобно OS>развивать и поддерживать систему. Плагин к браузеру тоже подойдет, но OS>при этом либо своих пользователей ограничите в выборе операционной OS>системы и браузера, либо будете поддерживать несколько плагинов для OS>разных систем и браузеров.
ОСь — всегда Windows. А на счет нескольких плагинов — значит единого стандарта нет? ну тогда нуно смотреть, какие возможности предоставляет конкретный браузер. Для IE я вроде даже видел какой то пример, суть была в том, что отдаешь браузеру свою реализацию IDispatch и из джава скрипта странички можешь дергать методы этого диспатча. если для FF мона организаввать что нить подобное, то вроде нормально все получается. две обвязки под браузеры напишем, а само ядро плагина — единое.
OS>Что касается электронных ключей, тут все не так однозначно. Ключи OS>используются для контроля использования специального софта на конкретной OS>вычислительной машине. Т.е. некий софт работает на железе только в OS>случае, если в составе железа есть специальное устройство — собственно OS>ключ. На клиентской машине используется браузер, чтобы ограничить его OS>работу придется создавать собственный браузер.
ну ограничивать работу браузера никто не собирается. Нуно просто собрать данные с ключа — и отослать их на сервер, вот собственно и все. Небольшая автоматизация, чтоб человеку не нужно было ручками всякие параметры ключа забивать.
А по поводу безопасности — ты не прав, кстати. программа априори взламываема, так что в принципе нет большой разницы, из браузера я работаю с ключем или из своей программы.
Один из вариантов сделать локальный прокси-сервер. Он может, к примеру, дописывать поля к http запросам или даже к телу запроса, а на стороне сервера их уже можно анализировать. Простой прокси делается на раз-два, минут за 15, как просто первый пример приложения на сокетах Допилить еще чуть-чуть и готов.
Если не охота с протоколами разбираться и прочим, то чуть более просто поднять просто локальный http сервер, который уже сам будет связываться с удаленным сервером. По сути то же самое, но не надо мучиться делать корректно работающий прокси, и не надо настраивать прокси в браузере.
ИМХО проще некуда. Чтобы тот же плагин к IE сделать надо гору документации прочитать и разобраться, а здесь обойдешься кратким описанием http протокола и справкой к сокетам.
А "веб-приложение" же под каким-то сервером крутиться будет все равно,
IIS, Apache? Если железяка к серверной машине подключена — серверное
расширение на базе ISAPI,
и др. api вплоть до CGI.
Здравствуйте, маген, Вы писали:
М>А "веб-приложение" же под каким-то сервером крутиться будет все равно, М>IIS, Apache? Если железяка к серверной машине подключена — серверное М>расширение на базе ISAPI, М>и др. api вплоть до CGI.
Здравствуйте, Рома Мик, Вы писали:
РМ>Здравствуйте, Jack128, Вы писали:
РМ>Один из вариантов сделать локальный прокси-сервер. Он может, к примеру, дописывать поля к http запросам или даже к телу запроса, а на стороне сервера их уже можно анализировать. Простой прокси делается на раз-два, минут за 15, как просто первый пример приложения на сокетах Допилить еще чуть-чуть и готов.
РМ>Если не охота с протоколами разбираться и прочим, то чуть более просто поднять просто локальный http сервер, который уже сам будет связываться с удаленным сервером. По сути то же самое, но не надо мучиться делать корректно работающий прокси, и не надо настраивать прокси в браузере.
РМ>ИМХО проще некуда. Чтобы тот же плагин к IE сделать надо гору документации прочитать и разобраться, а здесь обойдешься кратким описанием http протокола и справкой к сокетам.
ну на самом деле поднять web сервак у клиента или уж тем более прокси — это ИМХО слишком. А если у них уже стоит свой сервер? и неизвестно какой. а с другой стороны — клиент — это может быть бабушка божий одуванчик, которая в обморок упадет от страшный слов типа "web сервак"
А как написать плагин для IE — даже на этом сайте написано..
Тогда, как вариант, сделать приложение на основе WebBrowser.
"Jack128" <19362@users.rsdn.ru> wrote in message news:3623379@news.rsdn.ru... > Здравствуйте, маген, Вы писали: > > М>А "веб-приложение" же под каким-то сервером крутиться будет все равно, > М>IIS, Apache? Если железяка к серверной машине подключена — серверное > М>расширение на базе ISAPI, > М>и др. api вплоть до CGI. > > нет, железо подключено к клиентским машинам.
Jack128 wrote:
> ну на самом деле поднять web сервак у клиента или уж тем более прокси — > это ИМХО слишком. А если у них уже стоит свой сервер? и неизвестно > какой. а с другой стороны — клиент — это может быть бабушка божий > одуванчик, которая в обморок упадет от страшный слов типа "web сервак"
Так правильный web-сервак поднимается вот так "new Server(8080).start();". Единственное — порт свободный надо подобрать, но это тоже элементарно.
А вот прокси — это конечно плохая идея.
> А как написать плагин для IE — даже на этом сайте написано..
А у меня FF и в IE я работать не собираюсь.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Jack128 wrote:
>> ну на самом деле поднять web сервак у клиента или уж тем более прокси — >> это ИМХО слишком. А если у них уже стоит свой сервер? и неизвестно >> какой. а с другой стороны — клиент — это может быть бабушка божий >> одуванчик, которая в обморок упадет от страшный слов типа "web сервак" .>Так правильный web-сервак поднимается вот так "new Server(8080).start();". Единственное — порт свободный надо подобрать, но это тоже элементарно.
Угу, и JVM поставить -)
.>А вот прокси — это конечно плохая идея.
>> А как написать плагин для IE — даже на этом сайте написано.. .>А у меня FF и в IE я работать не собираюсь.
ну для FF/Opera/Chrome есть NPAPI, насколько я понял +/- аналог актив икса.
А не проще ли написать вэб сервис, который будет работать с железом, тогда вэб сервер будет запрашивать в удобочитаемом формате всю инфу и обмениваться ей.
Дополнительные плюсы: не нужно изобретать велосипед с шифрованием (сертификаты все-таки) и можно разнести железо с сервисом и собственно вэб сервер (и можно написать обычное приложение, работающее с сервисом ... много чего можно).
Доброго времени суток! Мир Вам! С уважением Clevelus.
Если мой ответ понравился — оцените, ни на что не влияет, но будет приятно.
Здравствуйте, Jack128, Вы писали:
J>ну на самом деле поднять web сервак у клиента или уж тем более прокси — это ИМХО слишком. А если у них уже стоит свой сервер?
Имелось ввиду, что твоя прога поднимет сервер при запуске на свободном порту, а не ставить apache. Это строк 30 кода на С.
J>клиент — это может быть бабушка божий одуванчик, которая в обморок упадет от страшный слов типа "web сервак"
Не надо пугать бабушку. Прога запускается, стартует сервер, потом сама вызывает браузер с адресом 127.0.0.1:xxxx.
J>А как написать плагин для IE — даже на этом сайте написано..
Мне лично в этом сложно разобраться: слишком много умных слов. Хотя есть люди которые кайфуют от такого. Все разные.
Jack128 wrote:
> Угу, и JVM поставить -)
А что её ставить? Её хоть с сидюка/флешки запускать можно, хоть методом распаковать-из-архива установить. А ещё gcj есть.
А ещё можно погуглить веб-сервак под другие языки/платформы, наверняка что-нибудь на C/C++ есть, простой нативный бинарь собрать можно.
>> > А как написать плагин для IE — даже на этом сайте написано.. > .>А у меня FF и в IE я работать не собираюсь. > ну для FF/Opera/Chrome есть NPAPI, насколько я понял +/- аналог актив икса.
Замучаетесь под каждый браузер * операционка по плагину писать/поддерживать.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Jack128, Вы писали:
J>2) писать плагин для браузера. J>вообще не представляю как это все делает. есть ли какой нить единый стандарт на это?? тот же flash вроде под все браузеры есть.
Я тут почитал ответы .... веб сервисы прокси...
А что в браузеры уже нельзя ActiveX использовать???
Напишите ActiveX встройте в страничку.
