On Mon, 3 Dec 2007 14:32:37 -0300 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:
> 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
agreed. an approach where we CAN do both would probably be best.
> > 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.
ecore trashes memory a lot more - every event is alloced :) in general efl is
very alloc-happy. it allocs LOTS of things all the time. its kind of a
requirement that your malloc subsystem is fast and very goof at this kind of
usage. :)
> > 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...
agreed it will be painful. i don't think we should force edje into a thumbnail
format - BUT eet is possibly useful there as its agnostic when it comes to
glib, qt, efl etc.. the gtnome/kde crowd as best i know do not have any such
"container format" handler to pack many data items compactly into a single file
with an easy api to access it again. so we are not competing.
> > 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.
yeah - a bit late now :) but this discussion is good. :)
> --
> 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
