LINUX.ORG.RU

Требуется совет по созданию серверного приложения


0

0

Здравствуйте!

Поставлена следующая задача: Разработать приложение, работающее в режиме сервера, принимающее некие задания (по TCP и по Web-интерфейсу), упорядочивающее эти задания в несколько очередей и постепенно обрабатывающее принятые задания. Задания сводятся к выборке информации из Интернета, поэтому должна быть работа с HTTP, HTTPS и FTP (причем достаточно гибкая). Для приемника заданий нужна поддержка авторизации. Web-интерфейс должен быть простым, но встроенным, без внешних серверов.

Какие инструменты для разработки (язык, библиотеки и т.д.) вы посоветуете? Удобство и скорость разработки - один из главных критериев, поэтому с С/С++ связываться не хочется.

anonymous

Ответ на: комментарий от theserg

Результат должен быть в виде одного демона. Никаких Apache и MySQL. PHP соответственно также отпадает. И зачем тут СУБД? Очереди хранить? Это можно и в обычных файлах делать. Или какой-нибудь DBM.

Perl - не знаю, боюсь не сильно легче С будет. Продвинутая работа с текстом кроме как в Web-интерфейсе не нужна, а в остальном Perl близок к С.

Уточню: выполнение заданий связано с достаточно нестандартными Интернет-запросами и, видимо, придется использовать сокеты (перловая LWP, например, не подходит).

anonymous
()

>Удобство и скорость разработки - один из главных критериев, поэтому с >С/С++ связываться не хочется.
Ага, напиши его на васике блин !
Так и скажи что нифига не программист, а то "связываться не хочется".
Я бы Тайсона то-же побил только "связываться не хочется" :))))

anonymous
()
Ответ на: комментарий от anonymous

>Результат должен быть в виде одного демона.

Для работы с протоколами http ftp итд в данный момент есть туева куча либ под каждый язык, в гугле найдете.

Но могу предложить наиболее быстрый способ написания монолитного демона, стырить исходники вышеприведенного софта. Впихать это все в один демон и вуаля. IMHO это быстрее чем писать то же самое с нуля.

Aleks_IZA
()

задоблаешся ты это делать. что на перле что на сях.

vilfred ☆☆
()

Java.

В книжке Ноутона и Шилдта в качестве учебного примера (!) рассматривается кэширующий proxy HTTP-сервер.

anonymous
()

Python или Rubi

С руби лично не общался но грят что те же яйцы токо в профиль.

Ну а на питоне (мне кажеться он более распространен) сам делаю что то похожее токо сильно сложнее... замечательно выходит! чувствую что сэкономил заказчику немало килобаксов. Счас вот на С++ писать кусок надо - скорость разаработки упала чуть ли не на порядок.....

AIv ★★★★★
()
Ответ на: Python или Rubi от AIv

>Java

Напрашивающийся выбор, но чисто субъективно - душа не лежит.

> Ruby и Python

Первое, что пришло в голову. Но у меня уже есть параллельно разрабатываемый проект на Python, а хочется разнообразия. Я себе эту задачку во многом для развлечения поставил.

Было бы любопытно услышать мнение по поводу применимости (и обоснованности применения или не применения) чего-то типа Haskel или Ocaml. Я с ними знаком лишь шапочно и с удовольствием бы познакомился поближе на реальной задаче.

anonymous
()
Ответ на: комментарий от anonymous

>Perl - не знаю, боюсь не сильно легче С будет. Продвинутая работа с текстом кроме как в Web-интерфейсе не нужна, а в остальном Perl близок к С.

Класический пример незнания перла. Потрать десять дней на изучение перла а потом за два-три дня получеш нужный тебе продукт

cvv ★★★★★
()
Ответ на: комментарий от theserg

> apache+php+mysql+perl

Самая распространенная, проверенная временем, технологическая связка. Про DBM -даже не думай. Понадобится одновременный доступ к очереди - начнется монтаж костылей и протезов...

anonymous
()
Ответ на: комментарий от anonymous

>> Java > Напрашивающийся выбор, но чисто субъективно - душа не лежит.

Зря. На Java эта задача решается очень просто. Web-интерфейс легко реализуется при помощи jetty. Работу с http, https и ftp поддерживает из коробки. Если встроенная поддержка покажется недостаточно гибкой, есть множество сторонних библиотек на любой вкус.

asso_w
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.