🚀 go-pugleaf

... 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>

... W dole szumi rzeka, w g�rze fruwa ptak
A JZ sobie idzie i �piewa sobie tak:

>>>>> 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.
>>
>> Jest przecie� "Connection".
>
> Ale nie polaczenie ciagle. Np. napisz w http klienta webwego emulujacego
> terminal ssh.

Ale to przecie� bez sensu. Napisz gr� 3D w SQLu.

> JZ

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

Grzegorz Staniak wrote:
> ... W dole szumi rzeka, w g�rze fruwa ptak
> A JZ sobie idzie i �piewa sobie tak:
>
>
>>>>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.
>
>
> Jest przecie� "Connection".

Poza tym w HTTP/1.1 jest przeca persistent connections. To �e to ma�o
kto implementuje to ju� problem lenistwa developer�w a nie z�ego
projektu protoko�u.

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>

... W dole szumi rzeka, w g�rze fruwa ptak
A JZ sobie idzie i �piewa sobie tak:

>>> Ale nie polaczenie ciagle. Np. napisz w http klienta webwego emulujacego
>>> terminal ssh.
>>
>> Ale to przecie� bez sensu.
>
> Nie takie bez sensu. Np. po porcie 80 wchodzisz na aplikacje ktora tym
> samym przedziera sie przez lokalne blokady portow i pozwala ci na dostep do
> uslug ktore normalnie mialbys niedostepne.

To jest tak czy owak dzia�anie wbrew za�o�eniom HTTP w celach
najprawdopodoniej sprzecznych z polityk� danych sieci. Innymi s�owy: nie po to
administrator blokowa� porty, �eby ludzie wychodzili do poblokowanych us�ug
tunelami po HTTP ;)

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

Dnia Tue, 17 May 2005 07:25:49 +0000 (UTC), Grzegorz Staniak 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.
>
> Jest przecie� "Connection".

Ale nie polaczenie ciagle. Np. napisz w http klienta webwego emulujacego
terminal ssh. Do takiego rodzaju polaczen trzeba socketow tcp i
wzbogaconego klienta. Np. flash albo aplet javy.

--
JZ

Dnia Tue, 17 May 2005 08:30:02 +0000 (UTC), Grzegorz Staniak napisa�(a):

>> Ale nie polaczenie ciagle. Np. napisz w http klienta webwego emulujacego
>> terminal ssh.
>
> Ale to przecie� bez sensu.

Nie takie bez sensu. Np. po porcie 80 wchodzisz na aplikacje ktora tym
samym przedziera sie przez lokalne blokady portow i pozwala ci na dostep do
uslug ktore normalnie mialbys niedostepne.

--
JZ

JZ wrote:
> Dnia Tue, 17 May 2005 08:30:02 +0000 (UTC), Grzegorz Staniak napisa�(a):
>
>
>>>Ale nie polaczenie ciagle. Np. napisz w http klienta webwego emulujacego
>>>terminal ssh.
>>
>>Ale to przecie� bez sensu.
>
>
> Nie takie bez sensu. Np. po porcie 80 wchodzisz na aplikacje ktora tym
> samym przedziera sie przez lokalne blokady portow i pozwala ci na dostep do
> uslug ktore normalnie mialbys niedostepne.

No to nie wiem jaki problem. Tunelujesz ssh w HTTP/1.1 i tyle. Ale to
przecie� nie ma nic wsp�lnego z Webem.

... 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>

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 ;)

On Mon, 14 May 2018 11:32:47 -0700 (PDT), bruniaczu@gmail.com wrote:

> W dniu wtorek, 10 maja 2005 11:14:12 UTC+2 użytkownik Qertoip napisał:

Archeologia rulez...

> Też uważam się (mimo kilku znanych chwytów) za początkującego. chcę zapytać czy: A.) Kiedy piszecie IDE (przyznaję się: jestem naprawdę NOOBem!) ma to może coś wspólnego z Python IDLE?

IDE - integrated development environment czyli środowisko z inteligentnym
edytorem, debugerem i różnymi narzędziami wspomagającymi.

--
pozdrawiam
Roman Tyczka