On Dec 3, 2007 1:41 PM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote:
> This is a little off-topic for the thread, but there are some long
> term changes I would like to see for epsilon eventually.
>
> 1. Split thumbnail generation into pluggable processes. If we can
> specify external commands for generating thumbnails, we reduce the
> amount of code necessary to support new formats. This also gives us
> robustness when a dependency mis-behaves and crashes the thumbnailing
> process.
I'd like to have the minimum overhead with the safest approach, for
that I'd like to have just one "worker" process, if it crashes (or
take too long to reply) it would be restarted... but fork+exec
everytime is a no go... general usecase (not just canola) is to
thumbnail jpeg/png, these can be considered pretty safe/stable and
wouldn't cause much trouble... however using emotion to provide movie
thumbnails or an svg/edje reader may cause problems due the
flexibility to do bad things :-P
> 2. Switch to dbus for client to server IPC. Many of the issues
> currently with the epsilon daemon stem from some initial problems with
> ecore_ipc, and the hacky conversion to ecore_con. Dbus is also
> targeted at remote method invocation, which is essentially the goal of
> the epsilon daemon communications.
I'm not really found of DBus, actually I was planning to have a
hand-written system to do the communication instead of ecore_{ipc,con}
because the messages are really simple and can be done to fit a fixed
size, much easier and fast to handle, also processing on peers could
avoid alloc/free and thus not trash the memory. If these are well
encapsulated like epsilon is today, I see no problem. Also, by having
such hand-written message system I'd not require ecore at all for the
server process, just the worker, it's good to have things as light as
possible.
> 3. Develop a dbus standard communication protocol with FDO. Ideally,
> we could get a protocol adopted by the major desktops which would
> allow for a single thumbnailing process to be present regardless of
> your application mix. For instance, if you are running nautilus under
> E and it handles thumbnailing requests, then we don't need to start a
> background epsilon process.
I doubt it worth the pain, because if we go FDO we must remove any
attempt to use .edj as thumbnail format, and it's a good alternative
if you want to provide movie thumbnail. Going "too generic" may hurt
more than help if nobody else use it, and believe me these guys are
hard to get using done by others, you know the NIH syndrome...
> These don't really help the release schedule for iNDT, but I think
> they would create a better long term result.
As for INdT today, yes, it won't help, but it's good to discuss the
long term so we can help. Probably I'll hack some nasty epsilon2 to
get it done in time, but I'll not even commit to CVS, it'll stay in
staff.get-e.org GIT... after we have something good for the long term,
then I can help with it and then convert canola to use it.
--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
