Re: Shipping Vera with 2.4
- From: Michael Meeks <michael ximian com>
- To: Bastien Nocera <hadess hadess net>
- Cc: Havoc Pennington <hp redhat com>, GNOME Desktop Hackers <desktop-devel-list gnome org>, GST <setup-tool-hackers ximian com>
- Subject: Re: Shipping Vera with 2.4
- Date: 27 Feb 2003 14:51:14 +0000
Hi Bastien,
On Thu, 2003-02-27 at 14:14, Bastien Nocera wrote:
> > It's very hard to compare a system that exists, and works
> > with one that does not.
>
> I've also got my very own thingo to do simple IPC, that I use in totem:
> $ cat bacon-message-connection.[ch] | wc -l
> 271
>
> And that replaces the whole of CORBA for simple IPC purposes.
Well yes it's small. The facts that again it's a type-unsafe, "send
string" API, with no way of ascertaining what the interfaces are, are
rather unfavourable.
There are also the following bugs/mis-features I saw with a brief
glance, correct me if I'm wrong:
* missing syscall error handling
* blocking accept
* not handling EINTR
* assuming non-blocking / short reads [ possibly in-spec,
perhaps better to use NON_BLOCK ].
* blocking connection write
* no error checking / short write handling on write
* server_cb locks in a tight loop on 'read' error
* looks like it creates an insecure, world writable /tmp
Unix domain socket -> instant, huge security hazard
* doesn't do collision checking => instant DOS attack.
> > I'd point you at the code in eg. gnome-terminal/terminal.c that does
> > the uniqueness stuff - it's a handful of lines, but of course - if you
> > want to detect errors, do activation etc. you get to write more lines of
> > code. Either way it's a fraction of the code.
>
> 110 lines, command-line parsing and relative->full path helper included
> in Totem so far.
Including several security bugs, the inability to handle signals etc.
etc.
None of that is particularly hard to fix: the message is simple however
- re-use code, preferably that tested over a long period.
> > Of course - we should have bonobo-activation tracking all apps, and
> > make that a standard feature of GnomeProgram. But of course, that would
> > be obstructed as soon as it's suggested - too similar to D/BUS.
>
> That's certainly a better idea than making Gnome apps use bonobo-conf
> instead of GConf.
As Havoc said the other day - GConf was not designed to store data;
bonobo-conf however - was. Thus - though it took a long time for the
truth to come out - in fact bonobo-conf was a very useful tool, (quite
apart from being able to handle structured data) - you could store data
in a controlled way.
Regards,
Michael.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]