🚀 go-pugleaf

Dnia Tue, 10 May 2005 23:29:19 +0200, Climbus napisał(a):

> Poprogramuj w Zopie bez  zaglądania do dokumentacji:)

Zope2, bo jego masz pewnie glownie na mysli, ma zle zaprojektowane API.
Kazdy to wie. Dopiero Zope3 to zmienia. Poza tym Zope nie jest przeciez
czescia standardowej biblioteki Pythona. To tylko jedna z aplikacji wiec
porownywanie go do standardowych bibliotek Javy jest glebokim
nieporozumieniem.

--
JZ

> Zope2, bo jego masz pewnie glownie na mysli, ma zle zaprojektowane API.
> Kazdy to wie. Dopiero Zope3 to zmienia.

W zopie3 jesteś w stanie pisać bez zaglądania do dokumentacji? niesądze

> Poza tym Zope nie jest przeciez
> czescia standardowej biblioteki Pythona. To tylko jedna z aplikacji wiec
> porownywanie go do standardowych bibliotek Javy jest glebokim
> nieporozumieniem.

Co masz na myśli mówiąc standardowa biblioteka javy? j2se, j2ee czy j2me?

Nie porównuje standardwych bibliotek.

Standardowa biblioteka o niczym nie świadczy, liczy się ogół dostępnych 
rozwiązań. Czym jest system system operacyjny bez oprogramowania jak nie 
zabawką?

Dnia Wed, 11 May 2005 00:02:02 +0200, Climbus napisał(a):

>> Zope2, bo jego masz pewnie glownie na mysli, ma zle zaprojektowane API.
>> Kazdy to wie. Dopiero Zope3 to zmienia.
> 
> W zopie3 jesteś w stanie pisać bez zaglądania do dokumentacji? niesądze

W ogole prawie nic w nim nie napisze, bo dopiero zaczalem czytac na jego
temat. Ale Zope3 to nie standardowa biblioteka Pythona ale konkretna,
calkiem zlozona aplikacja. Tylko ze podejrzewam iz sam jeden Zope3 jest
mniej zlozony niz dowolna z wielu technologii javy, np. J2SE czy JavaBeans,
Struts itp.

> Co masz na myśli mówiąc standardowa biblioteka javy? j2se, j2ee czy j2me?

Na przyklad. Java bez nich jest zupelnie bezuzyteczna. Tak jak Python bez
swojej biblioteki standardowej.

> Nie porównuje standardwych bibliotek.

A to dlaczego? Porownujesz standardowe biblioteki sunowskie z jakims
trzeciorzednym modulem napisanym przez Johna Browna? I to ma byc dobre
porownanie?

> Standardowa biblioteka o niczym nie świadczy, liczy się ogół dostępnych 
> rozwiązań. 

Tak, to prawda. Wszystko zalezy o *jakie* rozwiazania ci chodzi. Bo jesli o
te dotyczace wiekszosci codziennych zadan, przetwarzanie tekstow, plikow,
przewalanie czegos z i do internetu to Python ma doskonale i znacznie
lepsze rozwiazania od Javy.

> Czym jest system system operacyjny bez oprogramowania jak nie 
> zabawką?

Python nie jest systemem operacyjnym. Jest jezykiem wyposazonym w bardzo
dobra, bogata biblioteke standardowa w ktorej zrobisz wiekszosc rzeczy.

--
JZ

nierozumiemy się


>>Nie porównuje standardwych bibliotek.
> 
> A to dlaczego? Porownujesz standardowe biblioteki sunowskie z jakims
> trzeciorzednym modulem napisanym przez Johna Browna? I to ma byc dobre
> porownanie?

Jeżeli jakiś język ma być użyteczny to potrzebuję całego kompletu: 
biblioteka standardowa, dobre bibilioteki zewnętrzne oraz narzędzia. 
Sama biblioteka standardowa jest prawie bezuzyteczna w poważnych 
zastasowaniach. Tak samo nawet najlepszy system operacyjny jest do kitu 
jak nie ma dostępnego oprogramowania.

Dlatego porównuje ogół zagadnienia.

> Tak, to prawda. Wszystko zalezy o *jakie* rozwiazania ci chodzi. Bo jesli o
> te dotyczace wiekszosci codziennych zadan, przetwarzanie tekstow, plikow,
> przewalanie czegos z i do internetu to Python ma doskonale i znacznie
> lepsze rozwiazania od Javy.

Tak masz rację. Ma niektóre zrozwiązania które się nadają do czegoś 
więcej niz do skryptologii, ale wraz ze wzrostem skomlikowania projektu 
szala przechyla sie na stronę javy (i to szybciej niż myślisz).

> Python ... jest jezykiem wyposazonym w bardzo
> dobra, bogata biblioteke standardowa w ktorej zrobisz wiekszosc rzeczy.

cytat: "wiekszosci codziennych zadan, przetwarzanie tekstow, plikow, 
przewalanie czegos z i do internetu"

Tak masz rację

Dnia Wed, 11 May 2005 00:22:58 +0200, Climbus napisał(a):

> Jeżeli jakiś język ma być użyteczny to potrzebuję całego kompletu: 
> biblioteka standardowa, dobre bibilioteki zewnętrzne oraz narzędzia. 
> Sama biblioteka standardowa jest prawie bezuzyteczna w poważnych 
> zastasowaniach. 

Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo ja nie wiem
o czym piszesz. 

> Tak samo nawet najlepszy system operacyjny jest do kitu 
> jak nie ma dostępnego oprogramowania.

Zle postawiony problem. Najlepszy system bez dobrego oprogramowania do
realizacji *moich potrzeb* jest bezuzyteczny. Co mi po wielosci softu ktory
w moim konkretnym wypadku bedzie bezuzyteczny? Poza tym moze byc nawet
odwrotnie. Moze byc kiepski jezyk a dobre oprogramowanie. Np. PHP i
Invision Power Board, najlepsze forum jakie znam.

> Dlatego porównuje ogół zagadnienia.

Nie ma czegos takiego jak ogol. Zawsze sa konkrety. Inaczej rozmywa sie
cale twoje porownywanie, bo w praktyce zawsze masz do czynienia z
konkretami a nie z wszystkimi mozliwymi zastosowaniami. Uwazam, ze do
*naprawde* wiekszosci zastosowan java nie ma wcale lepszych od pythona
rozwiazan. A wiekszosc zastosowan to nie przeciez zadne ciezkie  serwery
klastrowe i przetwarzanie rozproszone.

--
JZ

JZ napisał(a):

> przejrzysta. Masz np. jakies uwagi do modulu re? :) A to ze sa inne

Z tym modulem re jako enterprajsem to wystrzeliles w kosmos :)

-- 
Przemek Wiśniewski

Dnia Wed, 11 May 2005 09:27:48 +0200, Przemek Wiśniewski napisał(a):

>> przejrzysta. Masz np. jakies uwagi do modulu re? :) A to ze sa inne
> 
> Z tym modulem re jako enterprajsem 

Chcesz powiedziec, ze to modul gowniany i niedopracowany? Nie rozsmieszaj
mnie. Chyba roznimy sie definicja slowa enterprise.

--
JZ

JZ napisał(a):
> Dnia Wed, 11 May 2005 09:27:48 +0200, Przemek Wiśniewski napisał(a):
> 
> 
>>>przejrzysta. Masz np. jakies uwagi do modulu re? :) A to ze sa inne
>>
>>Z tym modulem re jako enterprajsem 
> 
> 
> Chcesz powiedziec, ze to modul gowniany i niedopracowany? Nie rozsmieszaj
> mnie. Chyba roznimy sie definicja slowa enterprise.

Tak, masz jakas spaczona definicje.

-- 
Przemek Wiśniewski

Climbus wrote:
> 
>> Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma 
>> szans"
>> bo jest od 5 do 15 razy mniejszy. :))
> 
> Nie porównuje ilości lini tylko ilość dostępnych funkcjonalnośći.

No tu poniekąd obydwaj macie rację. Ilość linii jest b. ważna, bo 
znacznie ułatwa utrzymywanie, debugowanie, rozwijanie kodu. Natomiast 
funkcjonalność enterprise przy dużych projektach jest jeszcze ważniejsza 
- lepsza np. bezpieczna syrenka niż ferrari z ryzykiem wybuchu silnika 
10% (z góry mówię że nie mam nic do ferrari, wręcz przeciwnie, hehe)

>>> Mniejsza częstotliowść zaglądania do dokumentacji wiąze się z tym że 
>>> python nie ma prawie bibliotek klasy enterprise. 
>>
>> Jakies bzdury piszesz. Np. ktora biblioteka pythona nie jest "klasy
>> enterprise" i co to niby ma znaczyc? Pythonowe batteries included, czyli
>> biblioteka standardowa jest przeciez klasy enterprise, tzn. nadaje sie do
>> ciezkich, biznesowych zastosowan. Uchodzi za bardzo stabilna, potezna i
>> przejrzysta. 
> 
> 
> Ta jasne, powiedz to Robertowi:) Z tego co sobie przypominam to w xmlrpc 
> są jakieś niedoróbki, dokumentacja też nie jest wspaniała, a 
> przynajmniej ja nie mogę się w niej znaleźć.

Zgłaszam się do tablicy. Ogólnie większość prostej funkcjonalności w 
bibliotece std Pythona jest zrobiona dobrze, ale są jeszcze tu i tam 
jakieś krzaczki. Tyle, że ta cała bibliotek to jest na prawdę *prosta*, 
podstawowa funkcjonalność. Enterprise to jest właśnie Zope, Twisted, 
PEAK etc etc, czyli rzeczy trochę nie bardzo doszlifowane.

>> A to ze sa inne
>> projekty mniej lub bardziej dojrzale to inna sprawa. Tak jest wszedzie 
>> i w
>> kazdym jezyku.
> 
> 
> Ale tych dobrych w pathonie narazie jest mało w porównaniu z javą. 
> Przynajmniej takich, które zostały wypróbowane w dużych korporacjach.

Otóż to.

JZ wrote:
> Dnia Wed, 11 May 2005 09:27:48 +0200, Przemek Wiśniewski napisał(a):
> 
> 
>>>przejrzysta. Masz np. jakies uwagi do modulu re? :) A to ze sa inne
>>
>>Z tym modulem re jako enterprajsem 
> 
> 
> Chcesz powiedziec, ze to modul gowniany i niedopracowany? Nie rozsmieszaj
> mnie. Chyba roznimy sie definicja slowa enterprise.

regexy to standard we wszystkich językach gdzieś od końca lat 70... w 
tym sensie nie jest to enterprise. Soft enterprise = helpery, frameworki 
do pisania logiki biznesowej dużych, skomplikowanych aplikacji.

Dnia Wed, 11 May 2005 09:53:22 +0200, Przemek Wiśniewski napisał(a):

> Tak, masz jakas spaczona definicje.

Definicje sa kwestia umowna. Twoja jest tak samo spaczona jak kazda inna.
Od strony filozoficznej nie ma czegos takiego jak "prawdziwa" definicja
czegokolwiek. Zamiast operowac wiec takimi przymiotnikami lepiej zdefiniuj
co rozumiesz przez jakosc kodu na poziomie "enterprise"

--
JZ

JZ wrote:
> Dnia Wed, 11 May 2005 00:22:58 +0200, Climbus napisał(a):
> 
> 
>>Jeżeli jakiś język ma być użyteczny to potrzebuję całego kompletu: 
>>biblioteka standardowa, dobre bibilioteki zewnętrzne oraz narzędzia. 
>>Sama biblioteka standardowa jest prawie bezuzyteczna w poważnych 
>>zastasowaniach. 
> 
> 
> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo ja nie wiem
> o czym piszesz. 

Rozbudowana aplikacja webowa, proste
> 
> 
>>Tak samo nawet najlepszy system operacyjny jest do kitu 
>>jak nie ma dostępnego oprogramowania.
> 
> 
> Zle postawiony problem. Najlepszy system bez dobrego oprogramowania do
> realizacji *moich potrzeb* jest bezuzyteczny. Co mi po wielosci softu ktory
> w moim konkretnym wypadku bedzie bezuzyteczny? Poza tym moze byc nawet
> odwrotnie. Moze byc kiepski jezyk a dobre oprogramowanie. Np. PHP i
> Invision Power Board, najlepsze forum jakie znam.
> 
> 
>>Dlatego porównuje ogół zagadnienia.
> 
> 
> Nie ma czegos takiego jak ogol. Zawsze sa konkrety. Inaczej rozmywa sie
> cale twoje porownywanie, bo w praktyce zawsze masz do czynienia z
> konkretami a nie z wszystkimi mozliwymi zastosowaniami. Uwazam, ze do
> *naprawde* wiekszosci zastosowan java nie ma wcale lepszych od pythona

No nie wiem nie wiem... AspectJ, Strust, Hibernate, Spring, Eclipse...

> rozwiazan. A wiekszosc zastosowan to nie przeciez zadne ciezkie  serwery
> klastrowe i przetwarzanie rozproszone.

Dlatego, że implementacje innych języków/softu enterprise są w stanie 
zrobić na jednej maszynie to, do czego np. python+zope potrzebuje 
klastra, hehehehe.

Dnia Wed, 11 May 2005 10:07:09 +0200, RobertSzefler napisał(a):

> regexy to standard we wszystkich językach gdzieś od końca lat 70... w 
> tym sensie nie jest to enterprise. 

Regex nie jest czescia jezyka python (tak jak w ruby i perlu) ale jest to
oddzielny modul biblioteki standardowej tak jak w javie. I jest on tak samo
dojrzaly aby go uzywac w zastosowaniach biznesowych. Kazdy kod ktory jest
dojrzaly, czyli stabilny i dobrze zaprojektowany, jest klasy enterprise,
tzn. nadaje sie do zastosowan biznesowych a nie tylko do zabawy, czy
testow. Tak definiuje to pojecie.

--
JZ

JZ wrote:
> Dnia Wed, 11 May 2005 10:07:09 +0200, RobertSzefler napisał(a):
> 
> 
>>regexy to standard we wszystkich językach gdzieś od końca lat 70... w 
>>tym sensie nie jest to enterprise. 
> 
> 
> Regex nie jest czescia jezyka python (tak jak w ruby i perlu) ale jest to
> oddzielny modul biblioteki standardowej tak jak w javie. I jest on tak samo
> dojrzaly aby go uzywac w zastosowaniach biznesowych. Kazdy kod ktory jest
> dojrzaly, czyli stabilny i dobrze zaprojektowany, jest klasy enterprise,
> tzn. nadaje sie do zastosowan biznesowych a nie tylko do zabawy, czy
> testow. Tak definiuje to pojecie.

No to różnica ontologiczna. Sorry, ale dla mnie np. BaseHTTPServer nie 
ma nic wspólnego z klasą enterprise, mimo że, owszem, jest 
zaimplementowany poprawnie.

JZ napisał(a):
> Dnia Wed, 11 May 2005 10:07:09 +0200, RobertSzefler napisał(a):
> 
> 
>>regexy to standard we wszystkich językach gdzieś od końca lat 70... w 
>>tym sensie nie jest to enterprise. 
> 
> 
> Regex nie jest czescia jezyka python (tak jak w ruby i perlu) ale jest to
> oddzielny modul biblioteki standardowej tak jak w javie. I jest on tak samo
> dojrzaly aby go uzywac w zastosowaniach biznesowych. Kazdy kod ktory jest
> dojrzaly, czyli stabilny i dobrze zaprojektowany, jest klasy enterprise,
> tzn. nadaje sie do zastosowan biznesowych a nie tylko do zabawy, czy
> testow. Tak definiuje to pojecie.

Jesli robisz biznes przy pomocy re to ja wymiekam.

-- 
Przemek Wiśniewski

Dnia Wed, 11 May 2005 10:10:17 +0200, RobertSzefler napisał(a):

>> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo ja nie wiem
>> o czym piszesz. 
> 
> Rozbudowana aplikacja webowa, proste

A jak bardzo rozbudowana? I to wszystkie "powazne zastosowania" jakie
miales na mysli? :) 

>> Nie ma czegos takiego jak ogol. Zawsze sa konkrety. Inaczej rozmywa sie
>> cale twoje porownywanie, bo w praktyce zawsze masz do czynienia z
>> konkretami a nie z wszystkimi mozliwymi zastosowaniami. Uwazam, ze do
>> *naprawde* wiekszosci zastosowan java nie ma wcale lepszych od pythona
> 
> No nie wiem nie wiem... AspectJ, Strust, Hibernate, Spring, Eclipse...

Zartujesz. Przeciez Eclipse to tylko edytor. Mam mu przeciwstawic
Macromedia Dreamweawer MX 2004 albo Adobe Photoshop CS? Bija Eclipse na
glowe w swych zastosowaniach. :) A i Struts jest koszmarnie zamotane, zdaje
sie ze javowcy uciekaja od niego do Springa.

> Dlatego, że implementacje innych języków/softu enterprise są w stanie 
> zrobić na jednej maszynie to, do czego np. python+zope potrzebuje 
> klastra

Zope2 to nie jedyna mozliwosc. I w sytuacjach duzych korporacji, gdzie
problem sprzetu nie istnieje sprawdza sie tak samo dobrze, jesli nie
lepiej, niz rozwiazania javowe. Poza tym Zope to nie jedyne rozwiazanie. Sa
lzejsze, wystarczajace do zastosowan o mniejszej skali. I w takich
sytuacjach gdzie sa wieksze ograniczenia na zasoby sprzetowe,
zasobozernosci javy jest niedopuszczalna. Przerabialismy juz Tomcata i
Cocoon ktory doprowadzal procesor i zasoby serwera do ciezkiej
niewydolnosci serca. Pomijam juz kwestie znacznie dluzszego tworzenia kodu
w javie, bo to tez jest problem przekladajacy sie na koszty. 

Nie bez powodu czolowe firmy takie jak Sun, SAP, IBM zaczynaja calkiem
powaznie interesowac sie jezykami dynamicznymi, tu PHP.
http://www.php.pl/index.php/phppl/nowosci/wielkie_korporacje_zauwazyly_php

--
JZ

Dnia Wed, 11 May 2005 10:49:09 +0200, Przemek Wiśniewski napisał(a):

> Jesli robisz biznes przy pomocy re to ja wymiekam.

To rob biznes bez bibliotek javy. Powodzenia. :))

--
JZ

Dnia Tue, 10 May 2005 23:36:29 +0200, JZ <fake@spamerom.niet> napisał:

[...]

> Jakies bzdury piszesz. Np. ktora biblioteka pythona nie jest "klasy
> enterprise" i co to niby ma znaczyc?

Że nie pisali jej fani Star Treka.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 00:07:16 +0200, Climbus <climbusUSUNTO@barwa.pl> napisał:

>
>> Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma szans"
>> bo jest od 5 do 15 razy mniejszy. :))
>
> Nie porównuje ilości lini tylko ilość dostępnych funkcjonalnośći.

Tak z ciekawości: kto wprowadził do języka polskiego określenie
'te funkcjonalności' na miejsce 'tę funkcjonalność'?

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 10:10:17 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

[...]

>> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo janie wiem o czym piszesz.
>
> Rozbudowana aplikacja webowa, proste

Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
na bezstanowym protokole?

-- 
http://www.piotr.dembiński.prv.pl

... W dole szumi rzeka, w górze fruwa ptak
A Piotr Dembiński sobie idzie i śpiewa sobie tak:

>>> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo janie wiem o czym piszesz.
>>
>> Rozbudowana aplikacja webowa, proste
> 
> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
> na bezstanowym protokole?
 
Tak, masz rację, a cały świat się myli ;)

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Piotr Dembiński <pdemb@gazeta.pl> wrote:
> Dnia Wed, 11 May 2005 10:06:03 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:
> 
> [...]
> 
>> W guglach to parę skryptów na krzyż. IL&M to chyba do skryptowania
>> renderingu wykorzystują i to dobry przykład, idealne zastosowanie dla
>> Pythona. A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale
>> czy jesteś pewien, że oni tego używają ;) ;) ;)
> 
> Wojskowi mają lispy :)
	... pojawia się tez czesto slowo "tcl";-) Z powazaniem
								Adam Przybyla

Dnia Wed, 11 May 2005 16:09:13 +0200, Grzegorz Staniak <gstaniak@wp.pl> napisał:

> ... W dole szumi rzeka, w górze fruwa ptak
> A Piotr Dembiński sobie idzie i śpiewa sobie tak:
>
>>>> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo janiewiem o czym piszesz.
>>>
>>> Rozbudowana aplikacja webowa, proste
>>
>> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
>> na bezstanowym protokole?
>Tak, masz rację, a cały świat się myli ;)

Możliwe.

-- 
http://www.piotr.dembiński.prv.pl

... W dole szumi rzeka, w górze fruwa ptak
A Piotr Dembiński sobie idzie i śpiewa sobie tak:

>>>>> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo janiewiem o czym piszesz.
>>>>
>>>> Rozbudowana aplikacja webowa, proste
>>>
>>> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
>>> na bezstanowym protokole?
>>Tak, masz rację, a cały świat się myli ;)
> 
> Możliwe.
 
Cóż, pożyjemy - zobaczymy. Jakoś mi jednak trudno wyobrazić sobie nagły odwrót
od aplikacji webowych, webservices etc. w kierunku czegoś nowego. Jeśli
doczekamy nowej fali apliakcji sieciowych _nie_ na HTTP, to nie za pięć lat 
i pewnie nie za dziesięć. ATSD, HTTP jest - jak widać - powszechnie nierozumiany 
i niedoceniany, a sensownych nowych propozycji jak na lekarstwo.

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
> na bezstanowym protokole?

    Tak się wzburzyłem, że aż musiałem napisać. Zrozumiałbym gdybyś wskazał
na ubogość przeglądarki HTML jako interfejsu użytkownika, albo na
restrykcjach na urządzenia peryferyjne klienta.... Ale bezstanowość ?
Istnieje 10 dobrych, sprawdzonych rozwiązań na ten problem. Albo "problemik"
bardziej.

Piotr Dembiński wrote:
> Dnia Wed, 11 May 2005 10:10:17 +0200, RobertSzefler 
> <rszeflerUSUNTO@murator.com.pl> napisał:
> 
> [...]
> 
>>> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo janie 
>>> wiem o czym piszesz.
>>
>>
>> Rozbudowana aplikacja webowa, proste
> 
> 
> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
> na bezstanowym protokole?
> 

lame

jeśli twierdzisz, że nie można, to Twój problem, inni na tym zarabiają 
(nawet dużo) $ i ignorują Twoje zdanie...

RobertSzefler wrote:
> Piotr Dembiński wrote:
>> Dnia Wed, 11 May 2005 10:10:17 +0200, RobertSzefler
>> <rszeflerUSUNTO@murator.com.pl> napisał:
>>>> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo janie
>>>> wiem o czym piszesz.
>>> Rozbudowana aplikacja webowa, proste
>> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
>> na bezstanowym protokole?
> 
> lame
> 
> jeśli twierdzisz, że nie można, to Twój problem, inni na tym zarabiają
> (nawet dużo) $ i ignorują Twoje zdanie...

Protokół jest z natury bezstanowy i to wiele rzeczy utrudnia.
Ale to nie programiści rządzą światem, tylko pieniądze.

W tej chwili wiele rzeczy opartych na teoretycznie bezstanowym protokole
jest lepiej zoptymalizowanych, zaprojektowanych, wydajnych itp. niż w
rozwiązaniach pozornie "słusznych", a to wszystko dzięki wielokrotnym
iteracjom, ogromej ilości doświadczeń, naturalnej ewolucji rozwiązań i
technologii webowych itd.

Zdaje się, że mimo problemów niskopoziomowych nie ma już teraz odwrotu
od tego typu technologii - lepiej chyba teraz w nią inwestować i starać
się ją usprawniać (np. wspierając i pomagając w rozwijaniu technologii
W3C)..

Pozdrawiam
Maciej

Dnia Thu, 12 May 2005 12:21:21 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

[...]

>> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
>> na bezstanowym protokole?
>>
>
> lame
>
> jeśli twierdzisz, że nie można, to Twój problem, inni na tym zarabiają
> (nawet dużo) $ i ignorują Twoje zdanie...

Tak, ale w prawie każdej aplikacji webowej uzupełnia się HTTP
o zarządzanie sesją.  To trochę tak, jakbyś za każdym razem
musiał definiować sobie strcpy() pisząc w C :)

-- 
http://www.piotr.dembiński.prv.pl

Piotr Dembiński wrote:
> Dnia Thu, 12 May 2005 12:21:21 +0200, RobertSzefler 
> <rszeflerUSUNTO@murator.com.pl> napisał:
> 
> [...]
> 
>>> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
>>> na bezstanowym protokole?
>>>
>>
>> lame
>>
>> jeśli twierdzisz, że nie można, to Twój problem, inni na tym zarabiają
>> (nawet dużo) $ i ignorują Twoje zdanie...
> 
> 
> Tak, ale w prawie każdej aplikacji webowej uzupełnia się HTTP
> o zarządzanie sesją.  To trochę tak, jakbyś za każdym razem
> musiał definiować sobie strcpy() pisząc w C :)

No to właśnie dowód na to, że można coś sensownego na HTTP zbudować, 
choć oczywiście doskonały ten protokół nie jest. A ogólnie to masz rację :)

Piotr Dembiński napisał(a):
> Dnia Wed, 11 May 2005 10:10:17 +0200, RobertSzefler 
> <rszeflerUSUNTO@murator.com.pl> napisał:
> 
> [...]
> 
>>> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo janie 
>>> wiem o czym piszesz.
>>
>>
>> Rozbudowana aplikacja webowa, proste
> 
> 
> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
> na bezstanowym protokole?
> 

Jak wyobrazasz sobie protokol stanowy?

W chwili obecnej stan dorabiany jest w bardzo prosty sposob, zapisujemy 
w przegladarce cooki, w tym np: cookie z identyfikatorem sesji 
zarzadzanej przez serwer. To zupelnie wystarcza.

Moznaby co prawda wykroic jakis standard, ale nie mialoby to sensu, bo 
obecne rozwiazanie jest wystarczajace. Zamiast zaorac wszystko i stawiac 
cos od zera lepiej kombinowac ze starym do poki ma to sens.

-- 
Przemek Wiśniewski

Dnia Fri, 13 May 2005 19:00:56 +0200, Przemek Wiśniewski <asdffasd@daseasdf.com> napisał:

> Piotr Dembiński napisał(a):
>> Dnia Wed, 11 May 2005 10:10:17 +0200, RobertSzefler
>> <rszeflerUSUNTO@murator.com.pl> napisał:
>>
>> [...]
>>
>>>> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo janie
>>>> wiem o czym piszesz.
>>>
>>>
>>> Rozbudowana aplikacja webowa, proste
>>
>>
>> Aplikacje webowe to IMO porażka.  Jak można napisać coś sensownego
>> na bezstanowym protokole?
>>
>
> Jak wyobrazasz sobie protokol stanowy?

To jest oczywiście pytanie retoryczne :)

> W chwili obecnej stan dorabiany jest w bardzo prosty sposob, zapisujemy
> w przegladarce cooki, w tym np: cookie z identyfikatorem sesji
> zarzadzanej przez serwer. To zupelnie wystarcza.

Zapałki i guma do żucia.

> Moznaby co prawda wykroic jakis standard, ale nie mialoby to sensu, bo
> obecne rozwiazanie jest wystarczajace. Zamiast zaorac wszystko i stawiac
> cos od zera lepiej kombinowac ze starym do poki ma to sens.

Nie mówię o pominięciu HTTP, tylko o tym, że dla aplikacji webowych
w ich obecnym stanie samo HTTP to za mało.

-- 
http://www.piotr.dembiński.prv.pl

Piotr Dembiński napisał(a):

>> Moznaby co prawda wykroic jakis standard, ale nie mialoby to sensu, bo
>> obecne rozwiazanie jest wystarczajace. Zamiast zaorac wszystko i stawiac
>> cos od zera lepiej kombinowac ze starym do poki ma to sens.
> 
> 
> Nie mówię o pominięciu HTTP, tylko o tym, że dla aplikacji webowych
> w ich obecnym stanie samo HTTP to za mało.
> 

No ale JAK? Czego brakuje?

-- 
Przemek Wiśniewski

Przemek Wiśniewski <asdffasd@daseasdf.com> writes:

> Piotr Dembiński napisał(a):
>
>>> Moznaby co prawda wykroic jakis standard, ale nie mialoby to sensu, bo
>>> obecne rozwiazanie jest wystarczajace. Zamiast zaorac wszystko i stawiac
>>> cos od zera lepiej kombinowac ze starym do poki ma to sens.
>> Nie mówię o pominięciu HTTP, tylko o tym, że dla aplikacji webowych
>> w ich obecnym stanie samo HTTP to za mało.
>>
>
> No ale JAK? Czego brakuje?

Brakuje oczywistej rzeczy, jaką jest zarządzanie sesją dla konkretnego
użytkownika.  Obecnie stosowane są podpórki w rodzaju cookies 
i zapamiętywania haseł w przeglądarce.  Można by to ustandaryzować, 
nie sądzisz?

-- 
http://www.pdemb.prv.pl 

... W dole szumi rzeka, w górze fruwa ptak
A Piotr Dembiński sobie idzie i śpiewa sobie tak:

>> No ale JAK? Czego brakuje?
> 
> Brakuje oczywistej rzeczy, jaką jest zarządzanie sesją dla konkretnego
> użytkownika. 

To nie jest i nie powinno być zadanie dla protokołu transportowego takiego
systemu jak WWW.

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Grzegorz Staniak <gstaniak@wp.pl> writes:

> ... W dole szumi rzeka, w górze fruwa ptak
> A Piotr Dembiński sobie idzie i śpiewa sobie tak:
>
>>> No ale JAK? Czego brakuje?
>> 
>> Brakuje oczywistej rzeczy, jaką jest zarządzanie sesją dla konkretnego
>> użytkownika. 
>
> To nie jest i nie powinno być zadanie dla protokołu transportowego takiego
> systemu jak WWW.

Dlatego właśnie webapy są do bani :)

-- 
http://www.pdemb.prv.pl 

Piotr Dembiński napisał(a):
> Przemek Wiśniewski <asdffasd@daseasdf.com> writes:
> 
> 
>>Piotr Dembiński napisał(a):
>>
>>
>>>>Moznaby co prawda wykroic jakis standard, ale nie mialoby to sensu, bo
>>>>obecne rozwiazanie jest wystarczajace. Zamiast zaorac wszystko i stawiac
>>>>cos od zera lepiej kombinowac ze starym do poki ma to sens.
>>>
>>>Nie mówię o pominięciu HTTP, tylko o tym, że dla aplikacji webowych
>>>w ich obecnym stanie samo HTTP to za mało.
>>>
>>
>>No ale JAK? Czego brakuje?
> 
> 
> Brakuje oczywistej rzeczy, jaką jest zarządzanie sesją dla konkretnego
> użytkownika.  Obecnie stosowane są podpórki w rodzaju cookies 
> i zapamiętywania haseł w przeglądarce.  Można by to ustandaryzować, 
> nie sądzisz?
> 

I wygladaloby to nastepujaco: do HTTP dodanoby nowe naglowki 
Set-Session-Id oraz Session-Id, ktore robilyby dokladnie to samo co 
Set-Cookie i Cookie. Samo zarzadzanie sesja ma niewiele wspolnego z 
protokolem.

Dobrze jest jak jest, wszsytko sie miesci w istniejacych standardach.

-- 
Przemek Wiśniewski

Przemek Wiśniewski wrote:

> I wygladaloby to nastepujaco: do HTTP dodanoby nowe naglowki
> Set-Session-Id oraz Session-Id, ktore robilyby dokladnie to samo co
> Set-Cookie i Cookie. Samo zarzadzanie sesja ma niewiele wspolnego z
> protokolem.
> 
> Dobrze jest jak jest, wszsytko sie miesci w istniejacych standardach.

Ale te nagłówki mogłyby być obowiązkowe dla kolejnej wersji protokołu,
co wprowadziłoby jeden sposób obsługi sesji. Póki co standardu tutaj nie ma.

-- 
Maciej "Fiedzia" Dziardziel (fiedzia (at) fiedzia (dot) prv (dot) pl)
www.fiedzia.prv.pl

A hug is a great gift - one size fits all and its easy to exchange

Maciej Dziardziel <fiedzia@fiedzia.prv.pl> writes:

> Przemek Wiśniewski wrote:
>
>> I wygladaloby to nastepujaco: do HTTP dodanoby nowe naglowki
>> Set-Session-Id oraz Session-Id, ktore robilyby dokladnie to samo co
>> Set-Cookie i Cookie. Samo zarzadzanie sesja ma niewiele wspolnego 
>> z protokolem.
>> 
>> Dobrze jest jak jest, wszsytko sie miesci w istniejacych standardach.
>
> Ale te nagłówki mogłyby być obowiązkowe dla kolejnej wersji protokołu,
> co wprowadziłoby jeden sposób obsługi sesji. Póki co standardu tutaj nie ma.

Ew. można by pomyśleć nad wprowadzeniem protokołu znajdującego się
pomiędzy TCP a protokołami aplikacyjnymi, który służyłby właśnie 
obsłudze sesji użytkownika (vide model ISO/OSI).  Wtedy za jednym
zamachem 'obskoczyłoby się' FTP, HTTP i tak dalej :)

-- 
http://www.piotr.dembiński.prv.pl

Piotr Dembiński napisał(a):
> Maciej Dziardziel <fiedzia@fiedzia.prv.pl> writes:
> 
> 
>>Przemek Wiśniewski wrote:
>>
>>
>>>I wygladaloby to nastepujaco: do HTTP dodanoby nowe naglowki
>>>Set-Session-Id oraz Session-Id, ktore robilyby dokladnie to samo co
>>>Set-Cookie i Cookie. Samo zarzadzanie sesja ma niewiele wspolnego 
>>>z protokolem.
>>>
>>>Dobrze jest jak jest, wszsytko sie miesci w istniejacych standardach.
>>
>>Ale te nagłówki mogłyby być obowiązkowe dla kolejnej wersji protokołu,
>>co wprowadziłoby jeden sposób obsługi sesji. Póki co standardu tutaj nie ma.

Po co? Juz jest Set-Cookie i Cookie.

Co taki standard moglby dac? Przeciez obsluga sesji np: w Javie i PHP 
jest zupelnie automatyczna i odbywa sie w jeden sposob.

> Ew. można by pomyśleć nad wprowadzeniem protokołu znajdującego się
> pomiędzy TCP a protokołami aplikacyjnymi, który służyłby właśnie 
> obsłudze sesji użytkownika (vide model ISO/OSI).  Wtedy za jednym
> zamachem 'obskoczyłoby się' FTP, HTTP i tak dalej :)

W HTTP Cooka z sesja mozna ustawiac na konkretna domene i na konkretny 
katalog. Tak wiec, sesja nie moze byc zdefiniowana na warstwie nizszej 
niz HTTP. W FTP sesje w takim pojeciu jak w HTTP sa zbedne.

-- 
Przemek Wiśniewski

Użytkownik "Maciej Dziardziel" <fiedzia@fiedzia.prv.pl> napisał w 
wiadomości news:20050515120755.11F1.0.NOFFLE@fiedzia.homeip.net...
> Ale te nagłówki mogłyby być obowiązkowe dla kolejnej wersji 
> protokołu,
> co wprowadziłoby jeden sposób obsługi sesji. Póki co standardu tutaj 
> nie ma.

Jest niepotrzebny. Problemem jest w ogóle sama idea robienia GUI w 
hipertekście i związane z nią rozczłonkowanie aplikacji na tysiąc 
samodzielnych prohgramów muszących odtwarzać między sobą jakieś stany 
sesji. Nakładanie na to czegokolwiek więcej niż ciasteczka to trochę 
pudrowanie syfa.
Chyba krokiem w dobrą stronę są xformsy, i w ogóle dalsze pogrubianie 
klientów.
pozdrawiam,
Filip 

Dnia Sat, 14 May 2005 18:42:07 +0200, Przemek Wiśniewski napisał(a):

>> Nie mówię o pominięciu HTTP, tylko o tym, że dla aplikacji webowych
>> w ich obecnym stanie samo HTTP to za mało.
> 
> No ale JAK? Czego brakuje?

Np. ciągłości połączenia jakie daje gniazdo TCP. 

--
JZ

... W dole szumi rzeka, w górze fruwa ptak
A Piotr Dembiński sobie idzie i śpiewa sobie tak:

>>>> No ale JAK? Czego brakuje?
>>> 
>>> Brakuje oczywistej rzeczy, jaką jest zarządzanie sesją dla konkretnego
>>> użytkownika. 
>>
>> To nie jest i nie powinno być zadanie dla protokołu transportowego takiego
>> systemu jak WWW.
> 
> Dlatego właśnie webapy są do bani :)
 
... a może po prostu są inne. Jeśli WWW ma wykorzystywać swoje własne cechy
architekturalne, paradygmatem powinien być REST, nie SOAP. Całość stanu
wbudowana w strony serwisu, traktowanego jako graf stanów reprezentowanych
zasobów. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Grzegorz Staniak wrote:
> ... W dole szumi rzeka, w górze fruwa ptak
> A Piotr Dembiński sobie idzie i śpiewa sobie tak:
> 
> 
>>>>>No ale JAK? Czego brakuje?
>>>>
>>>>Brakuje oczywistej rzeczy, jaką jest zarządzanie sesją dla konkretnego
>>>>użytkownika. 
>>>
>>>To nie jest i nie powinno być zadanie dla protokołu transportowego takiego
>>>systemu jak WWW.
>>
>>Dlatego właśnie webapy są do bani :)
> 
>  
> ... a może po prostu są inne. Jeśli WWW ma wykorzystywać swoje własne cechy
> architekturalne, paradygmatem powinien być REST, nie SOAP. Całość stanu
> wbudowana w strony serwisu, traktowanego jako graf stanów reprezentowanych
> zasobów. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

A powiedz, dlaczego ludzie jak programują, to projektują raczej ręcznie 
automatów stanów, tylko używają regexów albo języków, czy to 
imperatywnych, czy funkcyjnych? To z reguły jest prostsze... (oczywiście 
nie zawsze)

RobertSzefler wrote:

> A powiedz, dlaczego ludzie jak programują, to projektują raczej ręcznie 

miało być "nie projektują" oczywiście

> automatów stanów, tylko używają regexów albo języków, czy to 
> imperatywnych, czy funkcyjnych? To z reguły jest prostsze... (oczywiście 
> nie zawsze)

... W dole szumi rzeka, w górze fruwa ptak
A RobertSzefler sobie idzie i śpiewa sobie tak:

>>>>To nie jest i nie powinno być zadanie dla protokołu transportowego takiego
>>>>systemu jak WWW.
>>>
>>>Dlatego właśnie webapy są do bani :)
>>  
>> ... a może po prostu są inne. Jeśli WWW ma wykorzystywać swoje własne cechy
>> architekturalne, paradygmatem powinien być REST, nie SOAP. Całość stanu
>> wbudowana w strony serwisu, traktowanego jako graf stanów reprezentowanych
>> zasobów. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
> 
> A powiedz, dlaczego ludzie jak programują, to projektują raczej ręcznie 
> automatów stanów, tylko używają regexów albo języków, czy to 
> imperatywnych, czy funkcyjnych? To z reguły jest prostsze... (oczywiście 
> nie zawsze)

A skoro nie zawsze, skąd wiesz że tak byłoby w tym przypadku?

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Grzegorz Staniak wrote:
> ... W dole szumi rzeka, w górze fruwa ptak
> A RobertSzefler sobie idzie i śpiewa sobie tak:
> 
> 
>>>>>To nie jest i nie powinno być zadanie dla protokołu transportowego takiego
>>>>>systemu jak WWW.
>>>>
>>>>Dlatego właśnie webapy są do bani :)
>>>
>>> 
>>>... a może po prostu są inne. Jeśli WWW ma wykorzystywać swoje własne cechy
>>>architekturalne, paradygmatem powinien być REST, nie SOAP. Całość stanu
>>>wbudowana w strony serwisu, traktowanego jako graf stanów reprezentowanych
>>>zasobów. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
>>
>>A powiedz, dlaczego ludzie jak programują, to projektują raczej ręcznie 
>>automatów stanów, tylko używają regexów albo języków, czy to 
>>imperatywnych, czy funkcyjnych? To z reguły jest prostsze... (oczywiście 
>>nie zawsze)
> 
> 
> A skoro nie zawsze, skąd wiesz że tak byłoby w tym przypadku?

To oczywiście nie jest argument, bo milion much może się mylić. Ale jak 
masz duży serwis z mieszanką zawartości statycznej, średnio- i wysoce 
dynamicznej, to większość ludzi używa sesji jako (równoważnego 
oczywiście użyciu automatu stanów) identyfikatora aktualnego stanu, bo 
to umożliwia w większym stopniu skupienie się na lokalnych własnościach 
problemu, a nie patrzenie na system jako całość. Ja nie mówię, że to 
lepsze, chociaż większość serwisów, które robiłem, przy użyciu 
paradygmatu REST byłoby zrobić *znacznie* trudniej.

... W dole szumi rzeka, w górze fruwa ptak
A RobertSzefler sobie idzie i śpiewa sobie tak:

>>>>... a może po prostu są inne. Jeśli WWW ma wykorzystywać swoje własne cechy
>>>>architekturalne, paradygmatem powinien być REST, nie SOAP. Całość stanu
>>>>wbudowana w strony serwisu, traktowanego jako graf stanów reprezentowanych
>>>>zasobów. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
>>>
>>>A powiedz, dlaczego ludzie jak programują, to projektują raczej ręcznie 
>>>automatów stanów, tylko używają regexów albo języków, czy to 
>>>imperatywnych, czy funkcyjnych? To z reguły jest prostsze... (oczywiście 
>>>nie zawsze)
>> 
>> A skoro nie zawsze, skąd wiesz że tak byłoby w tym przypadku?
> 
> To oczywiście nie jest argument, bo milion much może się mylić. Ale jak 
> masz duży serwis z mieszanką zawartości statycznej, średnio- i wysoce 
> dynamicznej, to większość ludzi używa sesji jako (równoważnego 
> oczywiście użyciu automatu stanów) identyfikatora aktualnego stanu, bo 
> to umożliwia w większym stopniu skupienie się na lokalnych własnościach 
> problemu, a nie patrzenie na system jako całość. Ja nie mówię, że to 
> lepsze, chociaż większość serwisów, które robiłem, przy użyciu 
> paradygmatu REST byłoby zrobić *znacznie* trudniej.

Być może tylko ze względu na przywyczajenia. Popatrz na sąsiedni wątek, gdzie
idzie dyskusja o frameworkach webowych - jakoś nie masz w niej problemu ze
spojrzeniem na całość i operowaniem dość złożonymi pojęciami w celu
argumentowania, dlaczego dana architektura oprogramowania ma sens, a inna nie.
Dlaczego akurat REST miałby być barierą nie do przejścia? Kwestia
przyzwyczajenia do określonych założeń. A pożytki z takiego podejścia naprawdę
duże - globalnie i lokalnie.

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Grzegorz Staniak wrote:

> Być może tylko ze względu na przywyczajenia. Popatrz na sąsiedni wątek, gdzie
> idzie dyskusja o frameworkach webowych - jakoś nie masz w niej problemu ze
> spojrzeniem na całość i operowaniem dość złożonymi pojęciami w celu
> argumentowania, dlaczego dana architektura oprogramowania ma sens, a inna nie.
> Dlaczego akurat REST miałby być barierą nie do przejścia? Kwestia
> przyzwyczajenia do określonych założeń. A pożytki z takiego podejścia naprawdę
> duże - globalnie i lokalnie.

No jasne, że są pożytki i to duże. Ale stosują się raczej do serwisów
A) poważnych
B) interoperowalnych z czymkolwiek innym
C) dobrze zaprojektowanych ;)

Ergo potrzebne dużo czasu. Fajnie, jakby go mieć ;)

Poza tym co innego interfejs zewnętrzny, co innego wewnętrzna struktura...

RobertSzefler wrote:
> Grzegorz Staniak wrote:
> 
>> Być może tylko ze względu na przywyczajenia. Popatrz na sąsiedni 
>> wątek, gdzie
>> idzie dyskusja o frameworkach webowych - jakoś nie masz w niej 
>> problemu ze
>> spojrzeniem na całość i operowaniem dość złożonymi pojęciami w celu
>> argumentowania, dlaczego dana architektura oprogramowania ma sens, a 
>> inna nie.
>> Dlaczego akurat REST miałby być barierą nie do przejścia? Kwestia
>> przyzwyczajenia do określonych założeń. A pożytki z takiego podejścia 
>> naprawdę
>> duże - globalnie i lokalnie.
> 
> 
> No jasne, że są pożytki i to duże. Ale stosują się raczej do serwisów
> A) poważnych
> B) interoperowalnych z czymkolwiek innym
> C) dobrze zaprojektowanych ;)
> 
> Ergo potrzebne dużo czasu. Fajnie, jakby go mieć ;)
> 
> Poza tym co innego interfejs zewnętrzny, co innego wewnętrzna struktura...

Nie no dobra, czepiam się. Sam kiedyś byłem fanem-chuliganem RESTa ;)

... W dole szumi rzeka, w górze fruwa ptak
A RobertSzefler sobie idzie i śpiewa sobie tak:

>>> Być może tylko ze względu na przywyczajenia. Popatrz na sąsiedni 
>>> wątek, gdzie idzie dyskusja o frameworkach webowych - jakoś nie masz w niej 
>>> problemu ze spojrzeniem na całość i operowaniem dość złożonymi pojęciami w celu
>>> argumentowania, dlaczego dana architektura oprogramowania ma sens, a 
>>> inna nie. Dlaczego akurat REST miałby być barierą nie do przejścia? Kwestia
>>> przyzwyczajenia do określonych założeń. A pożytki z takiego podejścia 
>>> naprawdę duże - globalnie i lokalnie.
>> 
>> No jasne, że są pożytki i to duże. Ale stosują się raczej do serwisów
>> A) poważnych
>> B) interoperowalnych z czymkolwiek innym
>> C) dobrze zaprojektowanych ;)
>> 
>> Ergo potrzebne dużo czasu. Fajnie, jakby go mieć ;)

Trochę czasu, trochę upowszechnienia się samej idei, trochę przykładów dobrze
zrobionych serwisów, trochę wsparcia ze strony projektantów frameworków 
i narzędzi... Mam nadzieję, że powoli aplikacje webowe będą szły w tę stronę.
To jest poniekąd ich naturalny sposób funkcjonowania.

>> Poza tym co innego interfejs zewnętrzny, co innego wewnętrzna struktura...

Oczywiście. Bardzo przydałyby się frameworki ułatwiające budowanie aplikacji
respektujących REST.
 
> Nie no dobra, czepiam się. Sam kiedyś byłem fanem-chuliganem RESTa ;)

E, od razu chuliganem. To po prostu dobry pomysł jest.

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>