2014-04-01 14:22 GMT+02:00 "Jóhann B. Guðmundsson" <johannbg@xxxxxxxxx>:
>
> On 04/01/2014 11:57 AM, Christian Schaller wrote:
>>
>> Well I think the real disagreement here is what the products is supposed to be
>> about. The WG wants to create an integrated product that is clearly identifiable,
>> not a 'mix your own' cookbook. We want to the Workstation to be as clearlyidentifiable
>> and targetable a product as MacOSX is, while I think you want the workstation to be the
>> equivalent of shipping a random desktop system on top of Darwin and still
>> claim it is 'MacOSX'.
>>
>> Christian
>
>
> Which is equivalent of saying that the serverWG should tie them to a single
> server role.
I don't think this is quite precise. The Server WG is, essentially, inventing a new, single, D-Bus API for roles (and assuming a single glibc API for server implementation[1]) . On the desktop, we already have GTK[23], Qt[45], and more fundamentally disjoint alternatives, and from time to time actually matters whether applications are all using a single one, or many (e.g. new features have to be implemented once vs. ~four times).
Mirek>
> On 04/01/2014 11:57 AM, Christian Schaller wrote:
>>
>> Well I think the real disagreement here is what the products is supposed to be
>> about. The WG wants to create an integrated product that is clearly identifiable,
>> not a 'mix your own' cookbook. We want to the Workstation to be as clearlyidentifiable
>> and targetable a product as MacOSX is, while I think you want the workstation to be the
>> equivalent of shipping a random desktop system on top of Darwin and still
>> claim it is 'MacOSX'.
>>
>> Christian
>
>
> Which is equivalent of saying that the serverWG should tie them to a single
> server role.
I don't think this is quite precise. The Server WG is, essentially, inventing a new, single, D-Bus API for roles (and assuming a single glibc API for server implementation[1]) . On the desktop, we already have GTK[23], Qt[45], and more fundamentally disjoint alternatives, and from time to time actually matters whether applications are all using a single one, or many (e.g. new features have to be implemented once vs. ~four times).
_______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
