From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 26 Feb 2007 01:16:15 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: =?koi8-r?B?y9XM2NTV0s7ZyiDPxtTP0MnL?= Message-ID: <20070225221615.GC10614@mw.local.seiros.ru> References: <213712504.20070211084001@gmail.com> <20070211204306.GB4984@mw.local.seiros.ru> <45D0026C.7010905@stc.donpac.ru> <20070213100215.GB26842@mw.local.seiros.ru> <45D86126.10006@stc.donpac.ru> <45D9466A.1030709@stc.donpac.ru> <20070224120232.GB25454@mw.local.seiros.ru> <45E059BA.1010803@stc.donpac.ru> <20070225091813.GA8776@mw.local.seiros.ru> <45E205B9.3090006@stc.donpac.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45E205B9.3090006@stc.donpac.ru> Subject: Re: [room] =?koi8-r?b?98/Q0s/TINDPIFBIUCAoyczJIEkgSGF0ZSBQSFAp?= X-BeenThere: smoke-room@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: =?koi8-r?b?y9XM2NTV0s7ZyiDPxtTP0MnL?= List-Id: =?koi8-r?b?y9XM2NTV0s7ZyiDPxtTP0MnL?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 22:16:16 -0000 Archived-At: List-Archive: On Mon, Feb 26, 2007 at 12:55:05AM +0300, Eugene Prokopiev wrote: EP> Я не про BlockingChannelConnector вообще-то, а например, про EP> SelectChannelConnector ;) А, я его по той ссылочке не нашел. EP> Можно прочесть еще вот это - EP> http://www.webtide.com/downloads/whitePaperAjaxJetty.html EP> NIO позволяет обслужить меньшим количеством потоков больше запросов. Угу, теперь понял. EP> Т.е. пытается обыграть Erlang на его поле ;) . Да, подход Erlang с EP> практически неограниченным количеством легких потоков изящнее, но NIO, EP> похоже, в большинстве случаев работает не хуже. У Erlang преимущество другое -- распределнность возведенная в абсолют. А по производительности пытаться обогнать nginx дело неблагодарное, лучше его использовать как фронтенд. Ну или быть полным психом, и встраивать его код в свой :) Мне больше нравится первое. >>EP>>> Сейчас для одного совсем маленького web-проекта я использую DWR, там >>EP>>> работа ведется не в терминах http-запросов, а скорее в терминах RPC. GUI >>EP>>> на HTML (еще лучше здесь будет смотреться XUL), клиентская логика на >>EP>>> JavaScript, серверная - Java (точнее контекст Spring со встроенными в >>EP>>> него бинами Jetty, DWR, самого Spring и моими). Собственно DWR нужен, >>EP>>> чтобы из JavaScript дергать Java-код (бины, размещенные в контексте >>EP>>> Spring) и наоборот. Не факт, что тебе это подойдет, но посмотри. >>>>%-) > EP>> Не годится? ;) >> Много слоев. EP> 2 - это немного (если не считать переходники JS<->Java, JSON<->JavaBeans EP> и JavaBeans<->БД, но они взяты готовыми). Я с трудом представляю себе EP> задачу, в которой не требовалось бы разделять UI и основную логику EP> работы (разве что последняя отсутствует - например, простая форма для EP> ввода данных в БД) Логично. >> Сходу не въехать, а при том я бы хотел оставить портируемость >> большей части своего кода между языками. Да, я знаю что я псих. EP> Т.е. свой DSL и его интерпретатор/компилятор на java/php/... ? Ага, компилятор. Как я посмотрел в реальном приложении типа "простой документооборот для малого бизнеса", например, объем логики хоть и большой, но она вся тривиальная. И если писать такое на каком-нибудь PHP, то проверка параметров, и простейшая работа с БД будут занимать большую часть кода. На конструкции где полсотни строк кода валидации параметров, а потом строк пять реального кода я уже даже смотрю спокойно. Да, есть небольшие куски специфичного кода, но они занимают меньшую часть кода. И как раз эти куски разумнее портировать вручную, думая что делаешь. Хотя можно и для них свой DSL сделать, но столько я не выпью. Ибо для меня написание даже самого простого компилятора это дни работы. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- God is Real, unless declared as Integer.