On Mon, 2 Dec 2013 14:53:04 +0900 Cedric BAIL <[email protected]> wrote:
> Hello, > > I was expecting your reply :-) > > On Mon, Dec 2, 2013 at 1:25 PM, David Seikel <[email protected]> > wrote: > > On Mon, 2 Dec 2013 11:57:23 +0900 Cedric BAIL <[email protected]> > > wrote: > > > >> So I have Ecore_Avahi ready in a branch for inclusion in 1.9. I am > >> just wondering if I should make it a strong dependency or an > >> optional one. I am thinking about making it a needed dependency, > >> any though against that ? For those that don't know Avahi is a > >> network service announcement/browsing library around zeroconf and > >> Ecore_Avahi is just there to do the mainloop integration. It means > >> we can avoid using Avahi glib integration to do the same. > > > > I don't use Avahi. I've removed most of it from my desktop system. > > The bits that are left I can't remove coz it's integrated into half > > of everything. Why most of that stuff needs any sort of network > > integration is a mystery to me, it doesn't. It just depends on > > Avahi coz people thought "hey, every one needs Avahi". I'll bet > > that most people don't even know what it is (or any other zeroconf > > type system), and never actually use it. > > > > Now if there was some sort of zeroconf integration that didn't need > > mainloop support, and could easily support "library doesn't exist, > > so skip that", then that would be much better. Then I can remove > > all of it from my system. B-) > > So basically a turned on by default option will do :-) And > realistically you can't implement a network library without > integrating it into the mainloop, that's impossible. Erm, what part of what a zeroconf system actually does is needed in a mainloop? Let alone in the mainloop of non networking apps? Try removing the Avahi library from a recent Ubuntu system and boggle at all those pages and pages of apps that it wants to remove automatically. Serious design failure in there somewhere. The same likely applies to other popular Linux distros. The same happens with CUPS. Try to remove all of CUPS from an Ubuntu system, and suddenly it wants to remove your desktop. lol > But if you don't use it, then you don't link to it and don't > initialize it, so you can skip it. So long as I can turn it off, and also build an embedded OS version without more dependencies, I'm happy. > > >> In the mean time I have started working on integrating libassh > >> within Ecore, in a Ecore_Con_SSH library. I don't think that I > >> will make it for 1.9, but not sure yet. The question for this one > >> is a little bit different, libassh is pretty young and not > >> included in any distribution as far as I know. So should I do like > >> we do with some library and put it in our tree and keep it in > >> sync, or should I make it an optional library (at this stage it is > >> not going to be a strong dependency) ? > > > > What does it even do? > > Right now up to channel setup. It does come with two setup, either > using gcrypt or it's internal cipher. The internal one are limited to > a small subset, but provide a functional ssh for embedded target that > don't want to include and use gcrypt. Goal is to provide full feature > ssh/scp support and integration with a UI toolkit. Something no other > library can provide. I have spend enough time with libssh, libssh2 and > friends to say they are just useless for anything UI related. ssh is a command line thingy. Dropbear and friends are used in small embedded systems usually, they don't use gcrypt if I recall. It's all scriptable enough for any usage I have found, and I've scripted all sorts off odd shit with ssh. I don't see why GUI stuff is any different. Script it and use ecore exe, done. 'Tis the Unix way. B-) > >> Opinion ! > > > > Keep it all optional please. Every little extra non optional > > library added just bloats things out more for people that don't use > > that stuff. Sooner or later we'll be just as bloaty as GNOME or > > KDE. > > Definition of bloat may vary, for me the main issue with other DE, is > that they consume so much memory and resource in general that they get > in the way of what I am doing. So keeping our small footprint with > more feature is not something I see as impossible as you seems to > think it is. It's the bloat creep that I worry about. Sure, your two extra libraries are not much, but each addition encourages more additions. Sooner or later every fucking thing under the sun is included, coz someone thought it was a good idea at the time, and it really didn't add much extra bloat at the time, so why worry at the time? > > My embedded work particularly can do without every little extra > > library being added. Especially the stuff with a legally mandated > > "only include the stuff that is actually needed" requirement. Or > > to put it another way, if the government asks my client "Why does > > your machine include stuff for automated network discover and ssh, > > is that some sort of backdoor?", and all my client can say is "No > > idea, it's not actually used.", then the government says "Not > > approved.", and my client goes out of business. Government LAWS > > can be tough like that. > > Hehe, especially when that said implementation enable to write a ssh > server and a ssh client :-) That one will stay optional and disabled > by default until we get to enough working feature. I didn't even > upload it to a branch yet, so no hurry, but still you didn't answer > the question ! This section was asking for an opinion, I gave mine. B-) My "answer" was "Keep it all optional please." though. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
