Megkezdte a HTTP/2.0 kidolgozását az IETF
A W3C után az IETF is kezdi összekapni magát az SPDY-re épülő új tervezettel
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
Hojtsy Gábor:
"Karaktersorozatok sebessége" PHP-ben
Balogh Tibor:
Három kiterjesztés a Zend motor működésének megismeréséhez
dtaylor:
PostgreSQL telepítése és beállítása
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 1 | 2 | 3 | 4 | 5 |
Van idő...(?)
A szabványosítási munka
Tudom, de nem annyira
Azt pedig, hogy mikre kell / akarjuk használni, szintén eléggé tiszta. Ezek alapján simán (és körültekintően) meg lehet csinálni 1, max 2 év alatt.
Kommunikációs hiba, ha lassabb. Én mondjuk nem tudom, hogy kikkel és hogyan egyeztetnek, de ígyis-úgyis lesz egypár elégedetlen cég/szolgáltató, úgyhogy szerintem kár sokat lacafacázni rajta.
Behatárolni, leírni meg x munkaórába kerül, nem muszáj "egy embernek" csinálnia...
Azt pedig, hogy mikre kell /
gondolom mar tobb RFC-t is irtal, es tisztaban vagy az elore illetve visszafele kompatibilitas fogalmaval.
azt sem szabad elfelejteni, hogy tobb resztvevovel(webszerver fejlesztok, proxy szerver fejlesztok, browser fejlesztok, etc.) kell egyeztetni, a velemenyuket kikerni, vitas kerdeseket rendezni, megfelelo idorahagyassal, es minden valtoztatas utan ujra megcsinalni az egesz review process.
Itt a munka 95% a speci pontos kidolgozasa, ha nem rontanak el ott nagyon semmit (tervezesi hiba, nem definialt viselkedes, etc.), akkor az alapjan implementalni mar valoban nem olyan veszes.
Viszont inkabb tartson tovabb a tervezesi fazis, mint hogy egy hibas specit kelljen workaroundolni az implementacioban.
Tyrael
Persze,
Szerintem épp a pontos specifikációra elég 1-2 év, ami - akár így is vehetjük - le is telt. De mivel - még mindig - nem tudom, hányfelé és hogyan kommunikálnak, lehet, hogy igazatok van. Nekem azonban úgy tűnik, hogy sok a "laca-faca", ha vmelyik érintett nem reagál normális idő(k) alatt, akkor "tojni kell a véleményére". Mert ugyanakkor az igény eléggé sürgős. Persze összeb..i sem szabad, rendben, hadd tudják ők, mennyi idő kell rá nekik.
(Most nézem: már megint te, megint engem - nem is kellett volna válaszoljak.)
A szabványosítási folyamatban
Megbocsátva :)
Csak az eredmény tényleg "jó legyen".
Kevés