Re: ORBit2 asyncness ...

[<dahaverk rockwellcollins com>]

>
> Then we can bin the adaptor, and make nautilus browsing nicer and
>faster - and provide a powerful tool to the rest of the platform. I'd
>far prefer to provide this than put work into making ORBit 'thread
>safe', which is going to be far harder, and make life even more complex
>for the programmer [ Sebastian agrees with this too ironicaly ].
>
 > What do you say ?
 >

 My thought is why hasn't ORBit-mt been merged into ORBit?

 I'm actually just starting to look at ORBit-mt...  We had some serious
 performance problems when we tried ORBit on our embedded target.

 Plus, the dependancies on newer glib versions etc for ORBit2 in the
 configure are very unfriendly toward porting.  I hate it when you set an
 option to be "no" such as "nls" in glib, then it changes it to a "maybe"
 and then stops the configure when it doesn't find the NLS
 includes/libraries.

 Which brings to mind another question, does ORBit2 truely depend on
 something that was fixed in the new version of Glib?...  Or was the
 configure dependancy just to force someone to update their "glib" because
 Glib development has been moving forward and they've ratcheted their
 version.

 just my 2cents.

 -Dave