On Fri, 28 Dec 2012 13:17:52 -0200 Lucas De Marchi <lucas.demar...@profusion.mobi> said:
> 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. you really have no clue. clueless. do you have any idea how much i fought when the session bus was removed to "save memory" (a few hundred kb)? do you? do you have any idea how much i yelled/grumbled/fought to get it back? do you? you don't have any clue. you are clueless. before you make such statements you may want to gain some. gustavo's position is "it's a mess" because it doesn't use dbus. that's an instant assessment without knowing that i did think about it and i decided against in this specific case. i don't hate dbus. i just think it has it's place, and this is not one of them. currently dbus support in efl is a mess. using it creates added messes on bigger scales. the day dbus is on every major os, and you get a new dbus session for each vt login, and bsd users have embraced and love dbus, and we don't have an unreleased edbus etc. etc. is the day i can consider dbus as usable for eevrything that isn't latency sensitive or high-traffic. the day all the os's have it as a kernel ipc service to avoid the extra bounces, is the day that this extra "gotcha" goes away. that day is not today. single instance was done and invented long before dbus was a twinkle in anyones eye... why does dbus need to re-invent it? eh? i thought about the options and chose the one that would work best in all situations. dbus was not that one. > > > > 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'm raising it as a point that dbus isn't always the one and only solution to everything. you choose your methods/technology depending on the situation. > 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. you will, because then all the bsd, osx etc. etc. people will still have the same problem. i don't spend my days porting to these other os's but i try and make decisions that won't rule them out or give them a hard time. "dbus in the kernel" has been "coming" for what.... 5? 8? years now? i heard about it so long ago i've forgotten. it's a patchset/rumor/vaporware that has existed almost as long as efl or e17... (yes i know there was some initial patchset - no idea where it went to etc.)... i'm not choosing dbus in the hope one day this may make it into the kernel is someone bothers, because if i had decided what to use based on this theory years ago... i'd still be waiting. if there's one thing i've learned and everyone re-learns again and again. don't bet or hope on someone else doing something when/if they say they will. you've got abot a 98% chance that they won't and then you're SOL if you based your plans on it. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 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_122912 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
