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

Итак, свойства:

• Это будет веб-приложение, единственный интерфейс — через броузер, AJAX обязателен.
  
• Только для Windows, причём про антикварные версии (до 2000) можно не думать.
  
• Предполагается запуск в виде Windows-сервиса.
  
• Ресурсоёмкость приложения небольшая (никаких сложных вычислений или больших объёмов данных).
  
• Трафикоёмкость тоже небольшая (никаких пересылок больших файлов, суперчастых обновлений, аудио/видео).
  
• Количество одновременных пользователей — от 1 до 20.
  
• Потребуется база данных, но требования к ней очень невысоки, так что с точки зрения производительности подойдёт любая (MySQL, PostgreSQL, SQLite, HSQL, etc.).
  
• Приложение будет коммерческим, то есть надо учитывть лицензионные требования всех компонентов (БД, например).
  
• Приложение должно обладать хоть какой-то защитой от несанкционированного копирования.

Цель, как обычно, минимизировать затраты ресурсов на разработку и поддержку такого предложения. Предпочтений по технологиям — никаких, на данном этапе рассматриваются все варианты, от Delphi + Indy + FireBird до Java + Jetty + HSQL (JIT-compiled).

Буду благодарен за любые цензурные соображения по теме

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

F>Возможно кто-то уже сталкивался с подобным выбором, поэтому хотелось бы услышать мнение коллег... Ситуация такова: с нуля будет создаваться некоторый продукт, ключевые свойства которого я постараюсь перечислить ниже. Выбор всех техологий полностью свободен, уникальный шанс сделать всё правильно

F>Итак, свойства:

F>

F>
• Это будет веб-приложение, единственный интерфейс — через броузер, AJAX обязателен.
  F>
• Только для Windows, причём про антикварные версии (до 2000) можно не думать.
  F>
• Предполагается запуск в виде Windows-сервиса.
  F>
• Ресурсоёмкость приложения небольшая (никаких сложных вычислений или больших объёмов данных).
  F>
• Трафикоёмкость тоже небольшая (никаких пересылок больших файлов, суперчастых обновлений, аудио/видео).
  F>
• Количество одновременных пользователей — от 1 до 20.
  F>
• Потребуется база данных, но требования к ней очень невысоки, так что с точки зрения производительности подойдёт любая (MySQL, PostgreSQL, SQLite, HSQL, etc.).
  F>
• Приложение будет коммерческим, то есть надо учитывть лицензионные требования всех компонентов (БД, например).
  F>
• Приложение должно обладать хоть какой-то защитой от несанкционированного копирования.
  F>

F>Цель, как обычно, минимизировать затраты ресурсов на разработку и поддержку такого предложения. Предпочтений по технологиям — никаких, на данном этапе рассматриваются все варианты, от Delphi + Indy + FireBird до Java + Jetty + HSQL (JIT-compiled).

F>Буду благодарен за любые цензурные соображения по теме

А может .NET и SQL Server 2005 ?

Поподробнее задачи опишите, а то не очень понятно зачем запуск в виде Windows сервиса и web интерфейс.

Совершенно не понятно что нужно. Спектр технологий колеблется от PHP до JEE/.NET.
БД — либо MySQL (традиционно), либо PostgreSQL (лично мне более приятно с это работать).
Все описанные требования — стандарт де-факто. Единственное, отмечу. Если речь идет о системе на продажу, глупо замыкаться в рамках технологий Windows. Технологии Windows в данном контексте это Delphi и .NET. Лучше выбрать что-нибудь скриптовое (PHP, Ruby, Python)или Java. Для всех есть отличные среды разработки.

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

G>А может .NET и SQL Server 2005 ?
Такой вариант несколько смущает необходимостью выкачивания многомегабайтного фрэймворка, опросы показывают, что более чем у половины нашей аудитории он не стоит.

G>Поподробнее задачи опишите, а то не очень понятно зачем запуск в виде Windows сервиса и web интерфейс.
Веб-интерфейс есть требование заказчика. Сервис — логичный вариант для случая, когда видимая часть приложения есть контент в окне броузера; сам "сервер" в это время крутится в виде сервиса и ничем себя не проявляет, ничем не смущает неискушённого юзера. Суть в том, что заметная часть инсталляций обещает быть однопользовательской, т.е. юзер скачал инсталляцию, проинсталлировал N раз нажав кнопку Next, кликнул на созданный в результате инсталляции ярлычок на десктопе, открылся броузер и там наше приложение. Всё, ничего больше юзер не видит и не должен видеть.

При таком сценарии, какие ещё могут быть варианты, кроме сервиса?

Что же касается более подробного описания задачи — с удовольствием, намекните только что ещё Вам интересно.

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

LV>Совершенно не понятно что нужно. Спектр технологий колеблется от PHP до JEE/.NET.
.NET несколько смущает необходимостью выкачивания многомегабайтного фрэймворка, опросы показывают, что более чем у половины нашей аудитории он не стоит.

LV>БД — либо MySQL (традиционно), либо PostgreSQL (лично мне более приятно с это работать).
А вот тут возникают упомянутые в изначальном посте вопросы с лицензией. Насчёт PostgreSQL не уверен, но насколько мне известно MySQL не особенно позволяет бандлить себя с коммерческим приложением. Или я не прав?

LV>Если речь идет о системе на продажу, глупо замыкаться в рамках технологий Windows.
Может и глупо, но market research говорит, что 94% потенциальной аудитории используют Windows 2000/XP/Vista.

LV>Технологии Windows в данном контексте это Delphi и .NET.
О .NET я уже написал, так что Delphi остаётся одним из основных претендентов... пока.

LV>Лучше выбрать что-нибудь скриптовое (PHP, Ruby, Python)или Java.
Java тоже в основных претендентах. В таком облегчённом варианте: сервлеты, Jetty, никаких EJB или application servers... Обязательно в JIT-откомпилированом варианте, чтобы избежать необходимости установки JVM отдельно.

Что же касается скриптовых языков, то все они хороши, особенно Python. Смущает только открытость их кода...

Есть вариант сделать костяк на Java, а бизнес-логику писать на Jython. По предварительным оценкам это в некотором роде пограничный случай: не совсем ясно, стоит ли игра свеч. Казалось бы разработка на Python раза в полтора быстрее, чем на Java, но с другой стороны решение в целом усложняется, увеличивается риск интеграционных проблем, и неясно, как такой "слоёный пирог" будет выглядет в плане производительности.

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

LV>>Лучше выбрать что-нибудь скриптовое (PHP, Ruby, Python)или Java.
F>Java тоже в основных претендентах. В таком облегчённом варианте: сервлеты, Jetty, никаких EJB или application servers... Обязательно в JIT-откомпилированом варианте, чтобы избежать необходимости установки JVM отдельно.

Это как?

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

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

LV>>>Лучше выбрать что-нибудь скриптовое (PHP, Ruby, Python)или Java.
F>>Java тоже в основных претендентах. В таком облегчённом варианте: сервлеты, Jetty, никаких EJB или application servers... Обязательно в JIT-откомпилированом варианте, чтобы избежать необходимости установки JVM отдельно.

L>Это как?

Так, например.

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

F>>>Java тоже в основных претендентах. В таком облегчённом варианте: сервлеты, Jetty, никаких EJB или application servers... Обязательно в JIT-откомпилированом варианте, чтобы избежать необходимости установки JVM отдельно.

L>>Это как?

F>Так, например.

Ну-ну.

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

F>>Так, например.
L>Ну-ну.

А почему нет? Т.е. до пилотирования пока не дошло, но пока всё выглядит реально. Или я что-то упускаю?

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

F>А почему нет? Т.е. до пилотирования пока не дошло, но пока всё выглядит реально. Или я что-то упускаю?

У меня есть большие сомнения в работоспособности подобных решений.

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

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

F>>А почему нет? Т.е. до пилотирования пока не дошло, но пока всё выглядит реально. Или я что-то упускаю?

L>У меня есть большие сомнения в работоспособности подобных решений.

Что за сомнения? На чём они основаны? На опыте? А поподробнее?
Иначе как-то очень голословно получается и общо.

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

L>>У меня есть большие сомнения в работоспособности подобных решений.

F>Что за сомнения? На чём они основаны? На опыте? А поподробнее?
F>Иначе как-то очень голословно получается и общо.

Тут часто на форуме мелькают сообщения о новых чудодейственных средствах, которые якобы позволяют не устанавливать .Net, да вот только при ближайшем рассмотрении всё это оказывается фуфлом полнейшим.
Не думаю, что в java с этим лучше. Хотя...

Firstborn пишет:
> G>А может .NET и SQL Server 2005 ?
> Такой вариант несколько смущает необходимостью выкачивания
> многомегабайтного фрэймворка, опросы показывают, что более чем у
> половины нашей аудитории он не стоит.

И процентов 70 из них просто не знают о том, что он стоит.

> инсталляций обещает быть однопользовательской, т.е. юзер скачал
> инсталляцию, проинсталлировал N раз нажав кнопку Next, кликнул на
> созданный в результате инсталляции ярлычок на десктопе, открылся броузер
> и там наше приложение. Всё, ничего больше юзер не видит и не должен видеть.

Все у вас как-то просто получается... Вы не для Интела пишете??? А то у
них тоже, установил, отрылось окошко браузера, загрузилось приложение и
нихрена не работает.

> При таком сценарии, какие ещё могут быть варианты, кроме сервиса?

Удаленный сервис? То есть приложение у вас, а вебморда у клиента? Аки
гугледокс, к примеру?

> Что же касается более подробного описания задачи — с удовольствием,
> намекните только что ещё Вам интересно.

Насколько конфиденциальные данные, местонахождение целевой аудитории?

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

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

L>>>У меня есть большие сомнения в работоспособности подобных решений.

F>>Что за сомнения? На чём они основаны? На опыте? А поподробнее?
F>>Иначе как-то очень голословно получается и общо.

L>Тут часто на форуме мелькают сообщения о новых чудодейственных средствах, которые якобы позволяют не устанавливать .Net, да вот только при ближайшем рассмотрении всё это оказывается фуфлом полнейшим.
L>Не думаю, что в java с этим лучше. Хотя...

А, ну понятно, то есть конкретного практического опыта не имеется. Что ж, тогда его надобно приобресть! Будем, наверное, пилотировать...

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

L>>Не думаю, что в java с этим лучше. Хотя...

F>А, ну понятно, то есть конкретного практического опыта не имеется. Что ж, тогда его надобно приобресть! Будем, наверное, пилотировать...

Интуиция — великая сила!
Удачи! Если не сложно, отпишитесь сюда по результатам.

Здравствуйте, Ромашка, Вы писали:

Р>Firstborn пишет:
>> G>А может .NET и SQL Server 2005 ?
>> Такой вариант несколько смущает необходимостью выкачивания
>> многомегабайтного фрэймворка, опросы показывают, что более чем у
>> половины нашей аудитории он не стоит.

Р>И процентов 70 из них просто не знают о том, что он стоит.

>> При таком сценарии, какие ещё могут быть варианты, кроме сервиса?

Р>Удаленный сервис? То есть приложение у вас, а вебморда у клиента? Аки
Р>гугледокс, к примеру?

Отнюдь. Большой процент инсталляций обещает быть вообще однопользовательскими, то есть и "серверный сервис" и броузер, его дёргающий, будут жить на одной машинке.

Р>Насколько конфиденциальные данные, местонахождение целевой аудитории?

Конфиденциальность начинается с определённого уровня конкретики
Могу сказать, что целевая аудитория практически ограничивается Nordic region.

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

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

L>>>Не думаю, что в java с этим лучше. Хотя...

F>>А, ну понятно, то есть конкретного практического опыта не имеется. Что ж, тогда его надобно приобресть! Будем, наверное, пилотировать...

L>Интуиция — великая сила!
L>Удачи! Если не сложно, отпишитесь сюда по результатам.

Спасибо!
Постараюсь, только не знаю пока, когда можно будет этих результатов ожидать...

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

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

G>>Поподробнее задачи опишите, а то не очень понятно зачем запуск в виде Windows сервиса и web интерфейс.
F>Веб-интерфейс есть требование заказчика. Сервис — логичный вариант для случая, когда видимая часть приложения есть контент в окне броузера; сам "сервер" в это время крутится в виде сервиса и ничем себя не проявляет, ничем не смущает неискушённого юзера. Суть в том, что заметная часть инсталляций обещает быть однопользовательской, т.е. юзер скачал инсталляцию, проинсталлировал N раз нажав кнопку Next, кликнул на созданный в результате инсталляции ярлычок на десктопе, открылся броузер и там наше приложение. Всё, ничего больше юзер не видит и не должен видеть.

F>При таком сценарии, какие ещё могут быть варианты, кроме сервиса?
А при таком сценарии приложение может быть многопользовательским? Или у вас где-то будет еще сервер крутиться? А где будет БД находится?
Вообще непонятно какие задачи должно решать ваше приложение.

Вообще необязательно чтобы само приложение было установлено на компьютере пользователя. Пусть работает где-то на удаленном сервере, а пользователи обращаются через web интерфейс.

Firstborn пишет:
> Отнюдь. Большой процент инсталляций обещает быть вообще
> однопользовательскими, то есть и "серверный сервис" и броузер, его
> дёргающий, будут жить на одной машинке.

Ты не понял. Никаких инсталяций. Клиент открывает браузер, жмет на
кнопочку и вот его приложение. А серверая часть с БД где-нить на
хостинге в новой зеландии.

> Р>Насколько конфиденциальные данные, местонахождение целевой аудитории?
>
> Конфиденциальность начинается с определённого уровня конкретики

Меня не интересует конкретика. Меня интересует насколько пользователь
считает свои данные конфиденциальными и на каких условиях согласен
доверить их вам.

> Могу сказать, что целевая аудитория практически ограничивается Nordic
> region.

Замечательно. Не парьтесь. Делайте интернет-сервис.

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

G>А при таком сценарии приложение может быть многопользовательским?
Идея такова, чтобы приложение можно было бы использовать и в однопользовательском режиме, и в многопользовательском (для небольших групп пользователей), причём для включения последнего просто поставить галочку "разрешить другим коннектиться тоже". Вопрос только в том, откуда "сервер" принимает коннекции — только от localhost, либо отовсюду.

G>Или у вас где-то будет еще сервер крутиться?
Где-то он в любом случае будет крутится. В однопользовательском режиме — на том же компе, за которым трудится единственный юзер.

G>А где будет БД находится?
Там же, где и "сервер". В идеале — embedded, вроде Firebird.

Здравствуйте, Ромашка, Вы писали:

Р>Firstborn пишет:

Р>А серверая часть с БД где-нить на
Р>хостинге в новой зеландии.
Нет, это не та схема по которой всё будет работать. Клиент получает инсталлятор и может его использовать только для себя, либо разрешить окружающим тоже к нему коннектится, становясь при таком сценарии сервером.

>> Могу сказать, что целевая аудитория практически ограничивается Nordic
>> region.

Р>Замечательно. Не парьтесь. Делайте интернет-сервис.
Увы. Не делаем.

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

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

G>>А где будет БД находится?
F>Там же, где и "сервер". В идеале — embedded, вроде Firebird.

А уверены, что встроенный Firebird умеет обрабатывать параллельные запросы? Или это не проблема?

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

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

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

LV>>>>Лучше выбрать что-нибудь скриптовое (PHP, Ruby, Python)или Java.
F>>>Java тоже в основных претендентах. В таком облегчённом варианте: сервлеты, Jetty, никаких EJB или application servers... Обязательно в JIT-откомпилированом варианте, чтобы избежать необходимости установки JVM отдельно.

L>>Это как?

F>Так, например.
Чувствуется, что вы кроме как на Delphi ни на чем особо и не писали. Отгадал?
1. Сколько будет стоить ваше приложение, если вы готовы не понятно зачем отдать 4500 баксов???
2. JVM можно вполне поставить с вашим приложением. Вести она 16Mb, а если урезать, то еще меньше будет.
3. JVM стоит на большинстве компьютеров.
И самое главное. Выбор платформы делается в первую очередь на основе типа приложения. Грубо говоря:
сайт-визитка: PHP
сайт уровня интернет магазина и не большого портала: Ruby On Rails, Python-фреймворки (я их не знаю, если честно)
корпоративный сайт плотно интегрированный в бизнес решения фирмы — JEE, .NET.

Лично мне не понятно, зачем выбирать для разработки решение, которое ну никак не позиционируется как средство создания сайтов? Да, там есть поддержка WEB-решений. Я сам делал гостевую книгу с помощью этого лет 6-7 назад. Но зачем? Почему бы не взять популярное средство, с большим комьюнити? Я не понимаю, зачем выбирать технологию, которая меня явно завязывает на определенной ОС. Если выбор другой технологии ни по каким параметрам не хуже, а независимость от ОС получается из коробки. Кстати, то что хочется именно веб-интерфейс, это уже намек на кроссплатформенность.

Теперь о БД. PostgreSQL полностью бесплатна. Насчет MySQL тоже есть такое опасение, где-то слышал. В Java 6 входит втроенная СУБД JavaDB (Derby).

PS Смотрите в сторону PHP, в нем можно как-то файлы шифровать. Подробности не знаю, только слышал краем уха.

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

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

G>>А при таком сценарии приложение может быть многопользовательским?
F>Идея такова, чтобы приложение можно было бы использовать и в однопользовательском режиме, и в многопользовательском (для небольших групп пользователей), причём для включения последнего просто поставить галочку "разрешить другим коннектиться тоже". Вопрос только в том, откуда "сервер" принимает коннекции — только от localhost, либо отовсюду.

То есть вы хотите реализовать функциональность веб-сервера?
1) Это не-очень просто (читай дорого).
2) Вам придется интерфейс зашить в приложение.
3) У вас могут возникнуть проблемы с установкой, если на компе уже стоит веб-сервер.
4) Возникнут проблемы с обеспечением безопасности (чтобы работать с embedded БД нужны будут права Local System).
5) Вам гораздо тяжелее будет обновлять ПО у клиентов.
6) Вам приедтся очень аккуратно писать чтобы все это работало как на XP, так и на Vista

Если вы реализуете нормальное web приложение, то:
1)Это будет гораздо быстрее и дешевле
2)Обновлять будет проще простого
3)Клиенту не понадобится ничего кроме браузера (кросплатформенность)
4)Можно будет использовать полновесную СУБД

Если хотите сделать все правильно то НЕ ПИШИТЕ НА DELPHI!!!

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

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

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

G>То есть вы хотите реализовать функциональность веб-сервера?
G>1) Это не-очень просто (читай дорого).

Неправда. Идеальный, читай в строгости блюдущий все требуемые RFC, делать не обязательно. Еслиб это было дорого, трех-копеечные модемы не имели бы своего веб-сервера для админки.

G>2) Вам придется интерфейс зашить в приложение.

Неправда. Есть БД. Есть скриптовые движки.

G>3) У вас могут возникнуть проблемы с установкой, если на компе уже стоит веб-сервер.

При установке, определить любой неиспользуемый порт (или назначить самому), в настройках его сохранить и в формируемом ярлыке URL будет иметь вид http://127.0.0.1:xxxx/. Не проблема в общем.

G>4) Возникнут проблемы с обеспечением безопасности (чтобы работать с embedded БД нужны будут права Local System).

Если это и так, какие проблемы?

G>5) Вам гораздо тяжелее будет обновлять ПО у клиентов.

С чего бы? Если этот вопрос заранее продумать проблем не будет.

G>6) Вам приедтся очень аккуратно писать чтобы все это работало как на XP, так и на Vista

Конкретнее, если можно.

G>Если хотите сделать все правильно то НЕ ПИШИТЕ НА DELPHI!!!

А на Delphi никак нельзя правильно сделать? Бред.

Здравствуйте, Аноним, Вы писали:

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

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

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

G>>То есть вы хотите реализовать функциональность веб-сервера?
G>>1) Это не-очень просто (читай дорого).
А>Неправда. Идеальный, читай в строгости блюдущий все требуемые RFC, делать не обязательно. Еслиб это было дорого, трех-копеечные модемы не имели бы своего веб-сервера для админки.
Интересно, что проще сделать: накатать несколько страниц на PHP/ASP.NET/JSP или писать собственный сервак, к которому также потребуется некоторый язык для создания динамических страниц, возможно тот же php?

G>>2) Вам придется интерфейс зашить в приложение.
А>Неправда. Есть БД. Есть скриптовые движки.
Есть, но их предтся самому писать или таскать с собой библиотеки. При этом человек не хочет ставить JVM или .NET Framework потому что они большие

G>>3) У вас могут возникнуть проблемы с установкой, если на компе уже стоит веб-сервер.
А>При установке, определить любой неиспользуемый порт (или назначить самому), в настройках его сохранить и в формируемом ярлыке URL будет иметь вид http://127.0.0.1:xxxx/. Не проблема в общем.
А удаленные клиенты сами догадаются какой у тебя порт настроен.

G>>4) Возникнут проблемы с обеспечением безопасности (чтобы работать с embedded БД нужны будут права Local System).
А>Если это и так, какие проблемы?
Сервис с правами Local System может делать ВСЕ. Придется очень сильно постараться чтобы не было уязвимостей в этой программе.

G>>5) Вам гораздо тяжелее будет обновлять ПО у клиентов.
А>С чего бы? Если этот вопрос заранее продумать проблем не будет.
Ну да, всего-то разослать обновление 10-50 клиентам и заставить их всех это поставить.
В варианте в web приложением на отдельном сервере придется заменить файлы в одном месте.

G>>6) Вам приедтся очень аккуратно писать чтобы все это работало как на XP, так и на Vista
А>Конкретнее, если можно.
У висты более строгая политика безопасности, то, что работает под XP, запросто может не запуститься под вистой. Каждый день такое вижу.
Конкретнее не скажу так как под висту ничего на Delphi не писал.

G>>Если хотите сделать все правильно то НЕ ПИШИТЕ НА DELPHI!!!
А>А на Delphi никак нельзя правильно сделать? Бред.
Да можно, но дорого. Современные средства типа ASP.NET и Java предоставляют гораздо больше возможностей.

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

G>Интересно, что проще сделать: накатать несколько страниц на PHP/ASP.NET/JSP или писать собственный сервак, к которому также потребуется некоторый язык для создания динамических страниц, возможно тот же php?

Во-первых, для PHP/ASP.NET/JSP нужно ставить сторонний сервер, пусть даже это будет IIS идущий в поставке Вин. Во-вторых для обеспечения работы этих плюшек нужен еще и определенный фреймворк (.Net/JVM/чего-нибудь-для-PHP). Относительно скриптовых движков -- есть бесплатный RemObject PascalScript, есть платный paxScript (C++, Pascal, JavaScript, Basic), есть биндинги для Lua, PHP. Очень приятно писать на Delphi и использовать тот же Паскаль в скриптах, ничего птичьего учить не придется

G>>>2) Вам придется интерфейс зашить в приложение.
А>>Неправда. Есть БД. Есть скриптовые движки.
G>Есть, но их предтся самому писать или таскать с собой библиотеки. При этом человек не хочет ставить JVM или .NET Framework потому что они большие

Движки, о которых я писал выше, кроме PHP, имеют мизерный размер и подключаются непосредственно к приложению (для Lua нужно dll'ки таскать)

G>>>3) У вас могут возникнуть проблемы с установкой, если на компе уже стоит веб-сервер.
А>>При установке, определить любой неиспользуемый порт (или назначить самому), в настройках его сохранить и в формируемом ярлыке URL будет иметь вид http://127.0.0.1:xxxx/. Не проблема в общем.
G>А удаленные клиенты сами догадаются какой у тебя порт настроен.

Если порт будет заранее назначен, то и проблем не будет. Хотя, это вообще не сильно большая проблема, учитывая, что работающий IIS (да и вообще внутренний веб-сервер) используется в основном у разработчиков.

G>>>4) Возникнут проблемы с обеспечением безопасности (чтобы работать с embedded БД нужны будут права Local System).
А>>Если это и так, какие проблемы?
G>Сервис с правами Local System может делать ВСЕ. Придется очень сильно постараться чтобы не было уязвимостей в этой программе.

Дырку для SQL-инъекции проморгать проще, чем переполнение буфера

G>>>5) Вам гораздо тяжелее будет обновлять ПО у клиентов.
А>>С чего бы? Если этот вопрос заранее продумать проблем не будет.
G>Ну да, всего-то разослать обновление 10-50 клиентам и заставить их всех это поставить.
G>В варианте в web приложением на отдельном сервере придется заменить файлы в одном месте.

Согласен, веб-приложение будет обновляться проще, но автор не хочет веб -- его право.

G>>>6) Вам приедтся очень аккуратно писать чтобы все это работало как на XP, так и на Vista
А>>Конкретнее, если можно.
G>У висты более строгая политика безопасности, то, что работает под XP, запросто может не запуститься под вистой. Каждый день такое вижу.
G>Конкретнее не скажу так как под висту ничего на Delphi не писал.

У Висты писать в PF нельзя Пишу под ней и для нее на Delphi -- ни каких проблем.

G>>>Если хотите сделать все правильно то НЕ ПИШИТЕ НА DELPHI!!!
А>>А на Delphi никак нельзя правильно сделать? Бред.
G>Да можно, но дорого. Современные средства типа ASP.NET и Java предоставляют гораздо больше возможностей.

Вы о каких возможностях говорите? Странички автоматом формировать? Вышеназваный paxScript, тоже имеет такой функционал (не говоря уже о библиотеках специально точеных на веб). В общем, это чисто пристрастная оценка.

Здравствуйте, Аноним, Вы писали:

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

G>>Интересно, что проще сделать: накатать несколько страниц на PHP/ASP.NET/JSP или писать собственный сервак, к которому также потребуется некоторый язык для создания динамических страниц, возможно тот же php?

А>Во-первых, для PHP/ASP.NET/JSP нужно ставить сторонний сервер, пусть даже это будет IIS идущий в поставке Вин. Во-вторых для обеспечения работы этих плюшек нужен еще и определенный фреймворк (.Net/JVM/чего-нибудь-для-PHP). Относительно скриптовых движков -- есть бесплатный RemObject PascalScript, есть платный paxScript (C++, Pascal, JavaScript, Basic), есть биндинги для Lua, PHP. Очень приятно писать на Delphi и использовать тот же Паскаль в скриптах, ничего птичьего учить не придется
Но это не отметает необходимости писать свой сервер

G>>>>4) Возникнут проблемы с обеспечением безопасности (чтобы работать с embedded БД нужны будут права Local System).
А>>>Если это и так, какие проблемы?
G>>Сервис с правами Local System может делать ВСЕ. Придется очень сильно постараться чтобы не было уязвимостей в этой программе.
А>Дырку для SQL-инъекции проморгать проще, чем переполнение буфера
В ASP.NET и Java есть параметризованные запросы и единый интерфейс доступа к данным. Там SQL инъекцию допусть очень сложно.

G>>>>5) Вам гораздо тяжелее будет обновлять ПО у клиентов.
А>>>С чего бы? Если этот вопрос заранее продумать проблем не будет.
G>>Ну да, всего-то разослать обновление 10-50 клиентам и заставить их всех это поставить.
G>>В варианте в web приложением на отдельном сервере придется заменить файлы в одном месте.
А>Согласен, веб-приложение будет обновляться проще, но автор не хочет веб -- его право.
Вот и пытаются тут автора наставить на "путь истинный".

А>Вы о каких возможностях говорите? Странички автоматом формировать? Вышеназваный paxScript, тоже имеет такой функционал (не говоря уже о библиотеках специально точеных на веб). В общем, это чисто пристрастная оценка.
А вы с помощью ASP.NET что-нибудь писали?

Архитектурное решение, предложенное автором, гораздо дороже реализации web приложения c помощью хотябы php.
С этим будете спорить?

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

А>>Во-первых, для PHP/ASP.NET/JSP нужно ставить сторонний сервер, пусть даже это будет IIS идущий в поставке Вин. Во-вторых для обеспечения работы этих плюшек нужен еще и определенный фреймворк (.Net/JVM/чего-нибудь-для-PHP). Относительно скриптовых движков -- есть бесплатный RemObject PascalScript, есть платный paxScript (C++, Pascal, JavaScript, Basic), есть биндинги для Lua, PHP. Очень приятно писать на Delphi и использовать тот же Паскаль в скриптах, ничего птичьего учить не придется
G>Но это не отметает необходимости писать свой сервер

Верно. Однако, простейший веб-сервер это несколько десятков строк.

G>>>>>4) Возникнут проблемы с обеспечением безопасности (чтобы работать с embedded БД нужны будут права Local System).
А>>>>Если это и так, какие проблемы?
G>>>Сервис с правами Local System может делать ВСЕ. Придется очень сильно постараться чтобы не было уязвимостей в этой программе.
А>>Дырку для SQL-инъекции проморгать проще, чем переполнение буфера
G>В ASP.NET и Java есть параметризованные запросы и единый интерфейс доступа к данным. Там SQL инъекцию допусть очень сложно.

В Delphi оно тоже есть, речь не о том Я к тому, что с логикой работы налажать проще.

А>>Согласен, веб-приложение будет обновляться проще, но автор не хочет веб -- его право.
G>Вот и пытаются тут автора наставить на "путь истинный".

Веб-приложение может быть архитектурно неприемлемо, и тому может быть множество причин.

А>>Вы о каких возможностях говорите? Странички автоматом формировать? Вышеназваный paxScript, тоже имеет такой функционал (не говоря уже о библиотеках специально точеных на веб). В общем, это чисто пристрастная оценка.
G>А вы с помощью ASP.NET что-нибудь писали?

Нет. Писал, очень мало, с ASP (COM объекты, опять же, на Delphi). Знаю, что ASP.NET сильно проще и удобнее, если вы к этому клоните

G>Архитектурное решение, предложенное автором, гораздо дороже реализации web приложения c помощью хотябы php.
G>С этим будете спорить?

Однозначно не скажешь, по причине того, что дешевле писать на том, что знаешь. Лично для меня, в глаза не видевшего PHP, но имеющего 13 летний Паскаль-опыт, на Delphi будет сильно дешевле.

Здравствуйте, Аноним, Вы писали:

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

А>Верно. Однако, простейший веб-сервер это несколько десятков строк.
Тут хочется воскликнуть: "Код в студию!".

А>В Delphi оно тоже есть, речь не о том Я к тому, что с логикой работы налажать проще.
С логикой всегда налажать можно. Но при разработке Windows сервиса надо думать о безопасности в любом случае.

А>>>Согласен, веб-приложение будет обновляться проще, но автор не хочет веб -- его право.
G>>Вот и пытаются тут автора наставить на "путь истинный".
А>Веб-приложение может быть архитектурно неприемлемо, и тому может быть множество причин.
По свойствам, представленным в первом посте web приложение подходит лучше всего.
А автор не дал вразумительных объяснений почему не подходит.

G>>Архитектурное решение, предложенное автором, гораздо дороже реализации web приложения c помощью хотябы php.
G>>С этим будете спорить?
А>Однозначно не скажешь, по причине того, что дешевле писать на том, что знаешь. Лично для меня, в глаза не видевшего PHP, но имеющего 13 летний Паскаль-опыт, на Delphi будет сильно дешевле.
А еще дешевле нанять пару человек, знающих ПХП, которые сварганят такое приложение за пару недель максимум

Кстати как у Delphi c web интерфейсами? В седьмой версии было никак, с тех пор что-нибудь изменилось?

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

G>Здравствуйте, Аноним, Вы писали:

А>>Верно. Однако, простейший веб-сервер это несколько десятков строк.
G>Тут хочется воскликнуть: "Код в студию!".

Могу привести демку из сетевой библиотеки Synapse (192 строки, я напишу еще меньше), надо?

А>>В Delphi оно тоже есть, речь не о том Я к тому, что с логикой работы налажать проще.
G>С логикой всегда налажать можно. Но при разработке Windows сервиса надо думать о безопасности в любом случае.

Сервис может работать и под ограниченной учеткой (если Firebird не требует чего-то большего). Да и вообще, это может быть не обязательно сервис, а просто приложение без морды стартующее вместе с системой.

А>>>>Согласен, веб-приложение будет обновляться проще, но автор не хочет веб -- его право.
G>>>Вот и пытаются тут автора наставить на "путь истинный".
А>>Веб-приложение может быть архитектурно неприемлемо, и тому может быть множество причин.
G>По свойствам, представленным в первом посте web приложение подходит лучше всего.
G>А автор не дал вразумительных объяснений почему не подходит.

Все может упираться в нежелание заниматься вопросами хостинга.

А>>Однозначно не скажешь, по причине того, что дешевле писать на том, что знаешь. Лично для меня, в глаза не видевшего PHP, но имеющего 13 летний Паскаль-опыт, на Delphi будет сильно дешевле.
G>А еще дешевле нанять пару человек, знающих ПХП, которые сварганят такое приложение за пару недель максимум

Быстро вы, однако, сроки определили... В пару недель: и с дизайном не облажаться, и закодировать нормально, и оттестировать... Сильно!

G>Кстати как у Delphi c web интерфейсами? В седьмой версии было никак, с тех пор что-нибудь изменилось?

Есть IntraWeb. Довольно интересная штука Но я этим не занимаюсь, честно говоря.

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

F>Буду благодарен за любые цензурные соображения по теме

Ну, раз веб-приложение, Windows да через броузер, то почему сразу не IIS/SQL2005 Express?

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

А>>Верно. Однако, простейший веб-сервер это несколько десятков строк.
G>Тут хочется воскликнуть: "Код в студию!".

using System;
using System.IO;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading;

namespace SimpleHttpServer
{
    class Program
    {
        static void Main(string[] args)
        {
            var acceptEvent = new ManualResetEvent(false);

            var listener = new TcpListener(IPAddress.Any, 8080);
            listener.Start();
            Console.WriteLine("Server started");

            while (true)
            {
                acceptEvent.Reset();
                listener.BeginAcceptTcpClient(
                    ar =>
                    {
                        using (var client = listener.EndAcceptTcpClient(ar))
                        {
                            acceptEvent.Set();

                            var buffer = new byte[client.ReceiveBufferSize];
                            using (var stream = client.GetStream())
                            {
                                var bytesRead = stream.Read(buffer, 0, buffer.Length);
                                var str = new string(Encoding.ASCII.GetChars(buffer, 0, bytesRead));
                                using (var writer = new StreamWriter(stream))
                                    if (str.StartsWith("GET"))
                                    {
                                        writer.WriteLine("HTTP/1.1 200 OK");
                                        writer.WriteLine();
                                        writer.WriteLine("<h1>Hello World!</h1>");
                                    }
                                    else
                                        writer.WriteLine("HTTP/1.1 500 Internal Server Error");
                            }
                        }
                    }, null);
                acceptEvent.WaitOne();
            }
        }
    }
}

Здравствуйте, Аноним, Вы писали:

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

G>>Здравствуйте, Аноним, Вы писали:

А>>>Верно. Однако, простейший веб-сервер это несколько десятков строк.
G>>Тут хочется воскликнуть: "Код в студию!".
А>Могу привести демку из сетевой библиотеки Synapse (192 строки, я напишу еще меньше), надо?
А скрипты прикрутить? Сколько в итоге получится?

А>Все может упираться в нежелание заниматься вопросами хостинга.
Без комментариев.

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

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

А>>>Верно. Однако, простейший веб-сервер это несколько десятков строк.
G>>Тут хочется воскликнуть: "Код в студию!".

AVK>

AVK>//skipped
AVK>

А теперь теперь приложение, имеющее web-морду на таком сервере.

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

G>Здравствуйте, Аноним, Вы писали:

А>>>>Верно. Однако, простейший веб-сервер это несколько десятков строк.
G>>>Тут хочется воскликнуть: "Код в студию!".
А>>Могу привести демку из сетевой библиотеки Synapse (192 строки, я напишу еще меньше), надо?
G>А скрипты прикрутить? Сколько в итоге получится?

Да собственно, только подключение скриптовых юнитов + инициализация окружения (сильно от контекста зависит). Кстати, я совсем забыл, что в Indy уже есть готовый веб-сервер

А>>Все может упираться в нежелание заниматься вопросами хостинга.
G>Без комментариев.

Вполне себе причина...

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

G>А теперь теперь приложение, имеющее web-морду на таком сервере.

Если речь о дотнете, то ASP.NET в 2.0 SP1 прикручивается без проблем. Если приложение простенькое и одно, то можно прикрутить что либо более простое, оптимизированное под конкретную задачу.