LINUX.ORG.RU

Веб-фреймворк на Objective-C

 ,


0

0

Некоторое время назад у меня появилась навязчивая идея сделать веб-фреймворк на Objective-C, это позволило бы писать веб-приложения, сохраняя гибкость и функциональность C, при этом пользуясь замечательным рантаймом Objective-C.

Основной проблемой была закрытость Foundation — базового набора классов Objective-C Apple. Веб-фреймвок, ограниченный серверной OSX, мало кому был бы интересен.

После изучения нескольких Opensource-клонов Foundation я остановил свой выбор на Cocotron. MIT-лицензия и хороший набор реализованного API — существенный плюс, но Cocotron разрабатывался как кросс-компилятор для Apple XCode.

FOW (Framework for Objective Web) основан на наборе моих скриптов сборки, позволяющих собрать GCC с патчами Apple (Objective-C 2.0) и Cocotron нативно на линуксе. Сам FOW собирается и работает как на Linux, так и на OSX.

Сегодня у меня был пробный запуск FOW на Linux-сервере (FastCGI через Lighttpd), который завершился полным успехом.

Для Objective-C уже существуют удобные библиотеки ORM и веб-темплейтов (да и CTemplates никто не запрещает использовать). А возможность собрать все это на Linux-машине, возможно, поднимет интерес к Objective-C среди не-эппловодов.

>>> Подробности

★★

Проверено: Shaman007 ()
Последнее исправление: cetjs2 (всего исправлений: 4)

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

> Подтолкнула меня к этому необходимость настоящих потоков в веб приложении, что на питоне я реализовать не смог (настоящих == не блокирующих друг-друга в GIL).

Лучше используйте мультипроцессирование.

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

> а в Инете попытки написать что-то подобное всегда вызывают бурю протеста. (по сути же, идея одна и та же)

В инете куда ниже окупаемость. Сайты плохо продаются, только рекламные копейки наползают. Разработка на компилируемых языках (а особенно языках БЕЗ автоматической памяти) - это безумно дорогое удовольствие.

А процессор в вебе не нужен. Все процессорные нагрузки уходят в БД.

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

>> Расскажете нам про свои 2M хитов в день и фреймворк на си...

> Google и C++?

Сергей Брин на ЛОРе??

А разве в Google только C++? С таким же успехом можно сказать, что wikipedia использует си, ибо работает в связке с базой данной (писанной на си) поверх сервера (написанного на си). Я имею ввиду написание контроллеров, собственно работу cgi.

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

>Дружочек, а википедия проект с достаточной посещаемость?

Дружочек, рассуждай о том, архитектуру чего ты знаешь. Википедия отдает 99.95% *статического* контента. Это значит, что однажды сгенерированная посредством php страничка кешируется на ~10 000 запросов. Поэтому неудивительно, что *у них* все работает.

В тех проектах, где *нельзя* кешировать страницы (а это - все проекты, где вывод зависит от конкретного пользователя: блоги, соц. сети, и т.п.), так вот, в этих проектах *всегда* так или иначе используется C или С++.

Попробуй понять, что закон Амдала никто не отменял, а значит, невозможно добиться работы "чиста ПоХаПэ-проекта" под большими нагрузками только увеличивая количество серверов. Приходится в том числе и менять язык реализации.

>Или у вы владеете ресурсом помощней?? Расскажете нам про свои 2M хитов в день и фреймворк на си...

Из российских компаний - Yandex, Mail.ru, Rambler, LiveJournal - все они в той или иной мере в своих вебпроектах пользуются кодом на С/C++.

Домашнее задание - ты самостоятельно ищещь соответствующие презентации и доклады (ключевые слова: РИТ, HighLoad, C++).

Второе домашенее задание - поискать презентации Yahoo, Google и т.п. и выяснить для себя, когда и для чего применяется PHP/Python, а когда - C и C++.

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

>Каков процент времени занимает выборка из базы и обработка результатов (на пхп, питон)?

Дружочек, пойми простую вещь: если у тебя проект типа "я и моя собака", то у *тебя* действительно самая медленная часть - это СУБД.

В больших же вебпроектах между СУБД и вебчастью давно и прочно стоит кеширующий сервер (самый распространенный - memcached). И при правильной архитектуре системы до СУБД доходит хорошо если 0.1% запросов (см. доклад-презентацию об архитектуре flickr). А все остальное отдается из кэша. В таких проектах основные тормоза - это выборка данных из кэша, их [ин]валидация и подготовка для вывода. Как раз те задачи, на которых съедается CPU и память.

>Разберитесь с этим, а после тяфкайте.

Я понимаю, истинные "Ъ" по ссылкам не ходят и гуглопоиском не пользуются. Тем не менее, уже второй раз советую: воспользуйтесь поиском и почитайте материалы об архитектуре высоконагруженных проектов.

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

>Я имею ввиду написание контроллеров, собственно работу cgi.

CGI в нагруженных проектах? Чините машину времени, Вы застряли в 1998 году.

В 2008 году технологии несколько ушли вперед: используются Apache + mod_(php|python|perl|c) и FastCGI - с теми же (php|python|perl|c). Причем, у FastCGI с cgi общего - только похожесть названий.

Там, где это действительно необходимо, модели, представления и контроллеры давно уже разрабатываются на c/c++. То, что это не используется крутыми ПоХаПэ-программерами на их мегасайтах с 1000 человек в день, не означает, что этого нет.

Повторяю, чините машину времени, Вы отстаете на 10 лет.

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

>В тех проектах, где *нельзя* кешировать страницы (а это - все проекты, где вывод зависит от конкретного пользователя: блоги, соц. сети, и т.п.),

можно кешировать куски страниц, или класть результаты выборки в тот же memcached, C/C++ для этого не нужны.

>так вот, в этих проектах *всегда* так или иначе используется C или С++.

для чего, например? почему C(++) а не, скажем, erlang?

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

>можно кешировать куски страниц, или класть результаты выборки в тот же memcached, C/C++ для этого не нужны.

Увы, выясняется, что нужны.

>>так вот, в этих проектах *всегда* так или иначе используется C или С++.

>для чего, например?

Для [де]сериализации данных при общении с кешем, для вывода XML потоков в веб (особенно - atomfeed текущих событий), для создания единого API, через которое ведется работа с БД, memcached и диском. Поверх которого делается Perl/Php/Python/whatever binding. Для сборки HTML (см. доклады "сервер-сборщик Mail.ru", "SUP Fabrik: сервер приложений C++", "Yandex Lego").

>почему C(++) а не, скажем, erlang?

Потому, что специалистов по erlang днем с огнем не найти. Вот в РБК используют некий джаббер-сервер, написанный на erlang.

Так на последней конференции, когда представителю РБК задали вопрос, откуда они берут программистов erlang, был получен ответ, что... э.... берут, но с трудом, и вообще, на всю Москву вменяемых спецов - 5 человек максимум.

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

> Дружочек, рассуждай о том, архитектуру чего ты знаешь. Википедия отдает 99.95% *статического* контента. Это значит, что однажды сгенерированная посредством php страничка кешируется на ~10 000 запросов. Поэтому неудивительно, что *у них* все работает.

Цифры, естественно, с потолка.

> В тех проектах, где *нельзя* кешировать страницы (а это - все проекты, где вывод зависит от конкретного пользователя: блоги, соц. сети, и т.п.), так вот, в этих проектах *всегда* так или иначе используется C или С++.

А разве вконтакте не на PHP? Как то не коррелирует это с вашим *всегда*. Или опять у вас будет оговорка "а вот в данном случае ввиду того, что X равно 2,17..."??

И ещё раз - "так или иначе" очень удобное выражение. PHP "так или иначе" использует Си, представьте себе.

Более того, я слабо представляю наколенную поделку на ObjC в составе 2M+ ресурсов.

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

>Цифры, естественно, с потолка.

Как угодно. Найдите другие цифры, на Гугле ведь не забанили, не так ли?

>А разве вконтакте не на PHP? Как то не коррелирует это с вашим *всегда*. Или опять у вас будет оговорка "а вот в данном случае ввиду того, что X равно 2,17..."??

И что именно не коррелирует-то?

>И ещё раз - "так или иначе" очень удобное выражение. PHP "так или иначе" использует Си, представьте себе.

Разумеется. "Так или иначе" - выражение, очень удобное для всех. Вот сделали PHP-binding к некой сишной библиотеке, которая умеет брать данные из БД, класть их в кэш, а кэш - [ин]валидировать. И получился вебпроект на чем? На PHP? На C? Или - на комбинированной технологии?

А в случае с Perl и Python ситуация еще сложнее - для этих языков писать binding существенно проще чем к PHP, поэтому и сишных/плюсовых модулей к ним много больше чем на PHP.

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

>Более того, я слабо представляю наколенную поделку на ObjC в составе 2M+ ресурсов.

Эту поделку - может быть. А то, что С++ в вебе используется - это факт, гугл/яндекс в вашем распоряжении, ищите информацию.

anonymous
()

а я, одевшись в скафандр, чтобы от яда защищал, грустно спрошу: а чего не использовать сам smalltalk?

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

> Вот сделали PHP-binding к некой сишной библиотеке, которая умеет брать данные из БД, класть их в кэш, а кэш - [ин]валидировать. И получился вебпроект на чем? На PHP? На C? Или - на комбинированной технологии?

тогда и надо взять тот язык, биндинги к которому пишутся легче, а накладные расходы -- меньше. Например, Haxe/NekoVM.

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

>скорость? тогда интересно было бы глянуть тесты

нет неинтересно. скорость вызова методов - удручающая, примерно как у питона, а возможно еще медленнее ( поиск по хэш таблице, sparse array в gcc runtime) + возможность добавлять категории (группы методов) в рантайме приводит к тому, что на любой вызов метода нужно защелкивать r/w lock. мистер David Stes (?) в своем poc - е вроде делал оптимизацию этого дела, но только для однопоточных сценариев. все объекты аллокируются в хипе, RAI нет, поэтому без гц - труба. гц используется консервативный (BoehmGC) или аллокаторы типа пулов или арен (в Cocoa вроде до сих пор так).

мне кажется лучше уж использовать чего нибудь типа Strongtalk или Smalltalk от степстоун и будет быстрее и удобнее.

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

>люто-бешено реквестирую SeaSide на Objective-C

в obj-c нет продолжений, замыкания добавили совсем недавно ( в сентябре ). о чем может идти речь? obj-c это не смолток и не лисп, seaside или uncommon web на нем - задача неподъемная.

имнсхо.

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

>мне кажется лучше уж использовать чего нибудь типа Strongtalk или Smalltalk от степстоун и будет быстрее и удобнее.

о strongtalk знаю, но afaik он так и остался исследовательским проектом ( вы его используете для чего-то in real world? ), а вот что такое "smalltalk от степстоун"? знаю про gemstone/smalltalk, платформу GLASS, про степстоун слышу впервые. can you elaborate?

p.s. сам использую gnu smalltalk и squeak.

volh ★★
()
Ответ на: комментарий от gods-little-toy

> И чё? Можно, для самых Ъ, в двух абзацах объяснить кому это надо? Какой-нибудь пример суперпуперности Оbjective-C для веба можно увидеть?

судя по твоему вопросу - тебе не надо. Иначе сходил бы по ссылке и посмотрел. Заодно задумался, в какой ситуации у этой штуки преимущества, и в чем одни недостатки. И сделал вывод самостоятельно нужна ли она лично тебе.

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

> Посмотри на презентацию CAS - это фремворк для разработки вебприложений на С++: http://cas.havoc.ru/doc/cas-server.ppt

Хоть просили и не меня, но я посмотрел. http://cas.havoc.ru/ Веб фреймворк, у которого нет сайта и дока в виндовых файлах. желание продолжать поуменьшилось.

anonymous
()

Давайте подеремся уже.

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

>Вот скажи, чем тебя обычный С не устроил или плюсы

>все занимаются сексом, но анальный секс на публике это нарущение

В Греции Сократ на площади мастурбировал и уверял, что это очень очищает. И что секс с мужчиной очень полезен.

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

> {gnu,squeak} smalltalk

Это ты спросто из общей любви к извращениям выбрал нефункциональный и тормозной диалекты?

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

я на смолтоке ничего серьезного не делаю, так что диалекты выбирались по одному критерию - они свободные.

squeak кстати не такой уж и тормозной, по сравнению с visualworks. а gnu smalltalk - он чтобы покопаться, и как гласит его лого, "smalltalk for those who can type". может среди смолтоков он и самый нефункциональный, но все-таки, "как все нормальные люди", содержит компилятор смолтока на смолтоке, простенький интерпретатор лиспа и компилятор пролога. мне, в общем, нравится.

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

> squeak кстати не такой уж и тормозной, по сравнению с visualworks.

по моим ощущениям очень даже такой уж. кроме того, неработающие замыкания в XXI веке - позор.

оно, конечно, понятно, что для поиграться их обоих вполне хватает.

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

>Дружок, если ты считаешь что на PHP можно написать вебпроект с любой посещаемостью, то твое место - в песочнице.

расскажите создателям фейсбука и фконтакта, ага

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

>Из российских компаний - Yandex, Mail.ru, Rambler, LiveJournal - все они в той или иной мере в своих вебпроектах пользуются кодом на С/C++.

в LiveJournal емнип много перла, это раз, и тормозит он периодически неслабо, это два.

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

> Я правильно понимаю, что этот велосипед с квадратными колесами написан, лишь бы пхп не использовать?

Анонимус, как всегда, тонко уловил проблематику. Всё, что угодно, только бы не пользоваться этим убожеством PHP, которое и языком-то не назвать

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

> Вот в РБК используют некий джаббер-сервер, написанный на erlang

Что же это за загадочный сервер? Прямо даже не знаю, что и предположить...

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

>> Вот в РБК используют некий джаббер-сервер, написанный на erlang

>Что же это за загадочный сервер? Прямо даже не знаю, что и предположить...

Ну же.... Это ведь так просто; первая доза бесплатно: google -> "jabber erlang".

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

> Ну же.... Это ведь так просто; первая доза бесплатно: google -> "jabber erlang".

Дурак, ты, анонимус. Брысь в словарь, ищи статьи "Ирония" и "Сарказм"

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

>>Дружок, если ты считаешь что на PHP можно написать вебпроект с любой посещаемостью, то твое место - в песочнице.

>расскажите создателям фейсбука и фконтакта, ага

Дружок, ты того-с, почитай/посмотри презентацию Алекса Москалюка про facebook. Откроешь для себя массу нового.

Еще почитай про thrift и его привязки к C++, Java, PHP, Python и Ruby. Подумай, зачем это парни из фейсбука сделали такое, если ПоХаПэ рулит.

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

>> Ну же.... Это ведь так просто; первая доза бесплатно: google -> "jabber erlang".

>Дурак, ты, анонимус. Брысь в словарь, ищи статьи "Ирония" и "Сарказм"

Сам дурак: брысь в словарь, ищи статьи "Ирония" и "Сарказм".

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

> но оно всё равно удобней и элегантней C++.

А разве есть что-то неудобней и уродливей С++? Разве что дельфопаскаль 90-ых, да и то боюсь только по первому пункту.

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

>> но оно всё равно удобней и элегантней C++.

>А разве есть что-то неудобней и уродливей С++? Разве что дельфопаскаль 90-ых, да и то боюсь только по первому пункту.

Можно по пунктам, что именно не нравится в C++?

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

> {gnu,squeak} smalltalk

> Это ты спросто из общей любви к извращениям выбрал нефункциональный и тормозной диалекты?

А какой следует выбирать диалект (из свободных), спрашиваю для общего развития?

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

> Можно по пунктам, что именно не нравится в C++?

Зачем? Лучше ответьте на вопрос, вот мол язык, который в своей нише и неудобней чем С++, и уродливее.

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

> Реквестирую Веб-фреймворк на ассемблере. > ты начни, товарищи подтянутся.

Не выйдет. Асмов многовато.

Тут курсач подтащили на асме Z9. У них (в лавке где работает студент) такой стандарт кодирования. Следовали ли отчислить студента?

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

>> Можно по пунктам, что именно не нравится в C++?

>Зачем? Лучше ответьте на вопрос, вот мол язык, который в своей нише и неудобней чем С++, и уродливее.

Иными словами, вы не в состоянии сформулировать недостатки C++ и пытаетесь слить тему.

Поздравляю с газификацией лужи, продолжайте дальше.

anonymous
()

больше фремворков, свободных, хороших и разных.

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

> Иными словами, вы не в состоянии сформулировать недостатки C++ и пытаетесь слить тему.

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

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

>> Иными словами, вы не в состоянии сформулировать недостатки C++ и пытаетесь слить тему.

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

Да все ясно с тобой, занятОй ты наш. Пукнул в лужу, отравил воздух - молодец. Иди троллить в другой теме, в этой у тебя не получается - вместо троллинга один сплошной слив.

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

а я ваще LittleSmalltalk использую, я не Ъ?

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

там много memcached, прежде всего.

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

а это неважно — есть или нет. и, кстати, Delphi весьма неплохой язык. вот VCL его — говно, а сам язык вполне.

(для паскалистов, буде проявятся: писал на Delphi около 10 лет) (для сишников, буде проявятся: писал на C/C++ около 10 лет)

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

[в былые времена достаточно было сказать php, как раздувался флейм минимум на десять страниц... Эх... А тут уже и C++ сказали, и php сказали, даже Apple сказали - а все бестолку...]

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

> А какой следует выбирать диалект (из свободных), спрашиваю для общего развития?

Из свободных мне не попадался ни один адекватный. Из бесплатыных - VisualWorks noncommercial.

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

> а это неважно — есть или нет. и, кстати, Delphi весьма неплохой язык. вот VCL его — говно, а сам язык вполне. (для паскалистов, буде проявятся: писал на Delphi около 10 лет)

Писали 10 лет, но так и не поняли, что и сам Дельфи в общем-то говно как язык? За 10 лет ни одной нужды в генериках не возникло?

> (для сишников, буде проявятся: писал на C/C++ около 10 лет)

Видимо надо было ещё на чём-то пописать.

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