[eside-ghost] [Itsas] ¿El fin de una era de internet frenada por el Internet Explorer? Google Chrome Frame

[Alfredo Beaumont]

2009/9/27 Jon Ander Hernandez <jonan.h a bildua gmail.com>:
> Buah ahora si que tenemos un verdadero flame!! Jejeje

Jeje, en el fondo sabes que estamos bastante de acuerdo... pero con matices ;)

>> No veo por qué va a ser flamer, ni qué relación tiene que webkit,
>> ahora, sea un proyecto multiempresarial. Webkit nació como un fork 'no
>> colaborativo' (o no 'polite' como dices más adelante)  y Google está
>> actuando de manera similar con Webkit.
>
> Tienes razón, aunque nunca he pretendido decir las formas durante el
> comienzo de Webkit fueran justas para KHTML.

Ya estamos de acuerdo un 1 punto ;)

>> ¿Cómo que no fue culpa del equipo de desarrollo de webkit?  El equipo
>> de desarrollo de webkit era apple, no eran personas aísladas. El
>> proyecto webkit nació como un fork con acceso restringido. El bugzilla
>> era tan sólo uno de los problemas, probablemente el menor: los
>> desarrolladores de khtml no tenían ni voz ni voto en el desarrollo de
>> webkit: ni bugs, ni código, ni decisiones de diseño, nada.
>
> Sip, pero una comunidad la forman sus desarrolladores, y el cabeza del
> proyecto Dave Hyatt formó parte del equipo que llevó a cabo la
> liberación de Mozilla desde Netscape, por eso lo de "su propia
> medicina" me parece un tanto flame, cuando sus miembros han estado
> involucrados en varios procesos de liberación, y cuando desde los
> comienzos se sabía que estaban negociando con Apple fórmulas para
> poder abrir más el proyecto : desde acceso especial a los
> desarrolladores de KHTML, hasta la liberación total en el 2005.

No digo que los miembros del equipo no quisieran ser más abiertos,
digo que no lo fueron, y estamos hablando que desde el 2002 hasta el
2005 la situación era prácticamente de imposible colaboración. Incluso
después del 2005, la 'liberación total' sólo es aparente. La política
de desarrollo de webkit es muchísimo más restrictiva que la de KDE:
todos los parches tienen que ser revisados (proceso bastante lento),
conseguir acceso directo al repositorio es otro proceso bastante
lento, etc. etc. Totalmente contrario a la política de KDE a la que
los desarrolladores de KHTML están acostumbrados.

> Y por otro lado tampoco creo que haya sido un grupo tan cerrado a la
> hora de aceptar decisiones de diseño, de hecho recuerda que integraron
> KSVG2/KDOM cuando el mantenedor de KHTML se negó a integrarlo, y se
> empecinó en que KSVG debía de seguir siendo un KPart y no parte del
> engine, lo cual supuso el suspenso indefinido del proyecto cuando
> estaban solo a falta de integrarlo en el trunk.

Precisamente, coger KSVG2/KDOM e integrarlo en contra del criterio de
los mantenedores de KHMTL no suena a aceptar decisiones de diseño. Más
bien suena a que como no me gusta lo que dices hago lo que quiero. Por
qué no se integró KSVG2/KDOM en KHTML sería motivo para otro debate.

>> Creo que esto es inexacto. Supongo que con 'integrar esfuerzos' te
>> refieres a 'abandonar sus esfuerzos y unirse a webkit' cuando, como
>> antes has comentado, hoy en día se trata de 2 proyectos que han
>> divergido bastante.
>
> IMHO creo que para tecnologías complejas de un costoso mantenimiento
> donde no es necesaria la dependencia sobre una tecnologia/toolkit
> concreta es mejor compartir y unificarse, como ya ocurre con proyectos
> como Poppler (motor PDF, desarrollado por la gente de Okular y de
> Evince) o HarfBuzz ("OpenType Layout engine", desarrollador por la
> gente de QT y GTK/Pango).

Esto también sería motivo de múltiples flames... Habría que coger cada
uno de estos proyectos y mirarlos más de cerca... y ver si realmente
se 'comparte' y 'unifica'. Deberías haber venido al GCDS, para ver
cómo se repartía brea especialmente con el tema de freedesktop. Así le
podrías haber preguntado en petit comité al mantenedor de poppler qué
opina del tema :D

>> Lo curioso es que tal como lo cuentas, parece que
>> sean los desarrolladores de KHTML los que no han querido colaborar con
>> webkit, cuando tal y como has dicho más arriba, fue totalmente al
>> contrario. Han sido los desarrolladores de webkit los que no han
>> querido integrar esfuerzos con KHTML, y por eso hay 2 motores
>> diferentes.
>
> Digo esto, porque Webkit propuso y refactorizó su código para que
> fuera toolkit agnóstico, mientras que en KHTML no se hizo nada
> similar, ni tampoco creo que se planteara en ningún momento, ¿Siendo
> KHTML totalmente dependiente de QT/KDE como iban el resto de proyectos
> a contribuir a KHTML?

Pues exactamente como se hizo webkit pero sin forkear.

>> Lo que comentas de que se ha acabado con la razón de ser
>> de KHTML... el tiempo lo dirá. De momento tenemos Qt 4.6 (y Qt 4.4
>> desde KDE 4.1) y KHTML sigue vivo.
>
> Hemos comenzado este hilo hablando del freno que supone IE al
> desarrollo Web ¿Realmente crees que se va a usar KHTML cuando los
> requisitos web sean más y más exigentes?

No veo mayor problema en usar KHTML. Es un buen motor. El mayor
problema puede venir de las máquinas virtuales de javascript, en las
que realmente se está trabajando bastante últimamente y hay bastante
innovación. En algún momento es probable que KJS también evolucione.

De todas formas, todo depende de lo que quieran hacer los
desarrolladores. La gente lleva años hablando de webkit en KDE, pero
aún no hay un navegador en KDE con webkit que ofrezca lo mismo que
KHTML, así que tampoco parece que el interés sea real. Si algún día
hay un interés real, y se consigue integrar webkit al mismo nivel que
KHTML, puede que la cosa cambie. De momento no es así.