On Fri, Dec 28, 2012 at 11:07 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Fri, 28 Dec 2012 10:16:15 -0200 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > >> On Friday, December 28, 2012, Carsten Haitzler wrote: >> >> > On Fri, 28 Dec 2012 01:58:49 -0200 Lucas De Marchi >> > <lucas.demar...@profusion.mobi <javascript:;>> said: >> > >> > > On Fri, Dec 28, 2012 at 12:28 AM, Enlightenment SVN >> > > <no-re...@enlightenment.org <javascript:;>> wrote: >> > > > Log: >> > > > work around edbus issues by forcing the mainloop to run at least one >> > > > cycle with some dummy things... in ipc launch mode. >> > > > >> > > > also make selection jump to end if a newline is there - as disussed >> > on >> > > > ml. >> > > >> > > could you detail a little bit what is the issue. Looking at the code, >> > > I couldn't understand why you put all this ipc stuff, instead of doing >> > > something like eve does. >> > >> > i put this in to: >> > >> > 1. avoid relying on dbus (not going to have a session bus when you are in >> > the >> > fb... for example :))... with e_dbus vs edbus at least for now this would >> > make >> > it hard to have terminology work with stable efl. >> > 2. avoid relying on a lower level windowing system (this can work in >> > wayland, >> > windows, framebuffer itself etc... tho fb means we cant do > 1 window... >> > if we >> > had "tabs"...)... >> > >> > dbus *IS* ipc... it just happens to be ipc with the added raised bar of a >> > dbus >> > daemon broker. i chose to do it the simple way - a simple unix socket. >> >> >> Let the mess begin. What an awful argument. Is that just being lazy or if >> we convert it you'll block the patch? > > how is it being lazy? it is actually a bit more work than using edbus. or > e_dbus. > > edbus is not released and depending on it will be a problem until a release of > edbus is out. > > e_dbus is being deprecated so adding e_dbus code now is silly. > > dbus wont EXIST as a session if you use terminology in the fb and that happens > to be an awesome selling point of it. the ability to just run terminology even > from inside of itself and get another "tab" even withni a single vt is a > really > nice thing. > > if dbus were used, this would tie multi-instance launch to a dbus session > environment. efreet already now has created a mess by using a session bus... > because now entrance is SCREWED. sure - terminology wont be in entrances > bucket, but it has a different bucket... and working in the fb without any > dbus > around AND having this feature work is important to me. > > dbus - let the mess begin. if you want to go to such extremes and just blanket > decide that if you don't use dbus you obviously have a mess. i'll take the > opposide view - if you use dbus you open a can of worms of a mess as per > the above. the atitude of using a specific named technology for the sake of > using it is going to guarantee a mess. i made a judgement call on this. it > just > doesn't happen to include your favorite technology. > i thought about using dbus. i chose against it for various reasons. part of it > is transitional, part is that terminology needs to work and have its > multi-instance stuff work in a non-dbus environment. i dont see how this is a > mess. it is not a source of any issues at all right now, and is unlikely to in > the future. we have a whole hulking infra for EXACTLY this reason. it's there > to > be used when the situation is right. it's called ecore-ipc. it exists for this > purpose. it's an alternative communications channel. it's not a mess. it means > this works regardless of dbus being there or not. i see no *BENEFIT* to making > it use dbus (edbus or e_dbus). i see only downsides. there are other > situations > for other people and needs. dbus may be appropriate and the best solution. in > this case it's not.
D-Bus is way far from being my favorite technology. But it's there and it works. "Single instance" is one of the things people keep reinventing the wheel, just because they can. I think you judgement is biased by your rage against D-Bus and IMO demonstrate a little of NIH - maybe because you were in contact with crazy tizen programs using d-bus for *intra*-process communication. Your words "d-bus/edbus/e_dbus is a mess; ecore_ipc isn't" demonstrates that very much. > > other situations where dbus is a poor choice: high volume data traffic or > where > latency is highly important (implementing x protcol via dbus would be one of > the > most braindamaged things you could ever due to it it having high volume and This is one of the situations that's very well known that d-bus is a poor choice. Just because it wasn't designed for this. Why are you raising this point? I am advocating that for this one feature - single instance process - d-bus should be used. I am hoping for the day d-bus is merged in the kernel so I don't have to answer all arguments like these. Lucas De Marchi ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
