eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingEmbedded HTTP Server › Re: Embedded HTTP Server
  • Data: 2020-06-23 23:13:07
    Temat: Re: Embedded HTTP Server
    Od: Maciej Sobczak <s...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    > > Więc na czym polega postęp?
    >
    > Na braku konieczności ręcznego tworzenia i zarządzania wątkiem.

    Ale przecież nie ma takiej konieczności w żadnym z przykładów.
    Natomiast w Twojej propozycji nie tyle nie ma takiej konieczności, co raczej nie ma
    takiej możliwości, bo schowałeś to "zarządzanie" w jakimś obiekcie, którego API nie
    podałeś.

    > Co mnie jako twórcę biblioteki obchodzi, że ktoś ma burdel w callbackach. Ja
    gwarantuję, że moje wątki się skończą jeśli skończą się callbacki.

    To jest ciekawa propozycja na kolejną wersję biblioteki.

    > Bo np. na jednym porcie masz dane dla userów, na drugim możesz dawać output z
    debuggera, profilera, co tam sobie robisz.

    I to trzeba mieć osobne porty do tego?
    Ja na przykład w tej konkretnej chwili podłączam się przeglądarką do jednego portu
    pod adresem groups.google.com a tam zdumiewające rzeczy, jedna grupa dla tych co
    lubią C++, inna dla tych, co nie lubią, itd. Masa różnych rzeczy, dla różnych
    odbiorców. Wyobrażasz sobie, różne rzeczy na jednym porcie mieć?

    > Bo mutexy są kosztowne czasowo.

    A tak w liczbach, mógłbyś?
    W sensie - w porównaniu do całkowitego czasu, który przeglądarce zejdzie na pełnej
    obsłudze, od konstrukcji zapytania GET do zakończenia wyświetlenia obrazu na ekranie?

    > > > To jest koślawe, sorry. W HTTP masz nie tylko akcje GET i POST, ale i chyba ze
    20 innych.
    > >
    > > Ale ja nie obiecuję obsługi tych 20 innych.
    >
    > Super, więc jak będę chciał mieć operację DELETE albo PUT, to muszę sobie szukać
    innego rozwiązania.

    Tak. Ewentualnie możesz zwrócić się do autora z uprzejmą prośbą, żeby to dorobił. Czy
    ten schemat pracy to jest dla Ciebie jakieś nowe zjawisko?

    > > I właśnie dlatego funkcje dla GET i POST *różnią się* sygnaturami.
    >
    > No fajnie, tylko to sztuczne rozróżnienie.

    Ale użyteczne w kontekście docelowego użycia.

    > > Czyli że:
    > >
    > > register(make_get_action(my_action));
    > >
    > > jest lepsze od:
    > >
    > > register_get_action(my_action);
    > >
    > > Sorry - ani trochę.
    >
    > Jest bardziej elastyczne i tyle. Ja wolę mieć jedną metodę i zrobić sobie
    odpowiednie konstruktory.
    > Zresztą, najlepiej byłby mieć register(my_action) i wybierać wariant za pomocą
    typetraits.

    Łomatko.
    Więc najwyraźniej potrzebujesz innej biblioteki. Normalna sprawa.

    > Chciałeś review, to masz. Ja wiem, że parsery klepane ręcznie nie mające testów to
    proszenie się o kłopoty, będą wcześniej, czy później.

    Nie zrozumiałeś. To, że testów nie ma w pakiecie razem z biblioteką, nie znaczy
    wcale, że parser nie był przetestowany - ani tym bardziej, że w ogóle nie było
    żadnych testów.

    W ogóle pomysł, że razem z produktem dostaje się w tym samym pudełku jego stanowisko
    testowe, to jakiś wymysł nie mający analogii w żadnej innej branży, nawet w tych
    inżynierskich.

    --
    Maciej Sobczak * http://www.inspirel.com

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: