Hi Mongrels, Anyone used Packet? http://rubyforge.org/projects/packet It''s a pure-Ruby (I think) evented framework. It might offer a nice way forward for 1.9''s system threads, JRuby, and Windows, all at once. Mongrel''s green thread queue doesn''t have a lot of life left in it. Evan -- Evan Weaver Cloudburst, LLC
It already has Mongrel support! ~/gems/packet-0.1.0/lib/packet_mongrel.rb Evan On Nov 21, 2007 10:19 AM, Evan Weaver <evan at cloudbur.st> wrote:> Hi Mongrels, > > Anyone used Packet? http://rubyforge.org/projects/packet > > It''s a pure-Ruby (I think) evented framework. It might offer a nice > way forward for 1.9''s system threads, JRuby, and Windows, all at once. > Mongrel''s green thread queue doesn''t have a lot of life left in it. > > Evan > > -- > Evan Weaver > Cloudburst, LLC >-- Evan Weaver Cloudburst, LLC
Yeah I ported evented mongrel to run on packet> it does run and is faster than threaded mongrel, not quite as fast as event machine evented mongrel. The one problem is that the first request after server boot hangs but then all requests after that are fine. I will continue some more work on this. I think it would be nice to provide this as official mongrel *opt in* functionality once it''s all worked out. Cheers- -Ezra On Nov 21, 2007, at 7:22 AM, Evan Weaver wrote:> It already has Mongrel support! > > ~/gems/packet-0.1.0/lib/packet_mongrel.rb > > Evan > > On Nov 21, 2007 10:19 AM, Evan Weaver <evan at cloudbur.st> wrote: >> Hi Mongrels, >> >> Anyone used Packet? http://rubyforge.org/projects/packet >> >> It''s a pure-Ruby (I think) evented framework. It might offer a nice >> way forward for 1.9''s system threads, JRuby, and Windows, all at >> once. >> Mongrel''s green thread queue doesn''t have a lot of life left in it. >> >> Evan >> >> -- >> Evan Weaver >> Cloudburst, LLC >> > > > > -- > Evan Weaver > Cloudburst, LLC > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
On Wed, 21 Nov 2007 12:45:01 -0800 Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:> > Yeah I ported evented mongrel to run on packet> it does run and is > faster than threaded mongrel, not quite as fast as event machine > evented mongrel. > > The one problem is that the first request after server boot hangs but > then all requests after that are fine. I will continue some more work > on this. I think it would be nice to provide this as official mongrel > *opt in* functionality once it''s all worked out.There''s several problems with Packet''s code, which I outlined for Evan over IRC earlier today: 1) It has EM code in it with the same GPL boilerplate. No GPL allowed as that will infect it with the viral license and open the door to malicious legal actions. 2) You rewind the data stream in your mongrel code while the parser can handle incremental parsing. 3) There''s several places where the code takes input from userland and embeds it in either an unpack or a regex thus allowing for userland format string attacks. 4) There''s quite a lot of dubious stuff going on, like using activesupport, adding weird class attribute accessors via class eval, and just other bad code all around. That''s just in about 10 minutes of browsing the source. If I can find that much wrong with it that quick, then it still needs lots of work. First and foremost is the GPL though. It''s a no-go if it has viral licensing and just borrows code from other projects that has GPL. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Nov 22, 2007 1:12 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> On Wed, 21 Nov 2007 12:45:01 -0800 > Ezra Zygmuntowicz <ezmobius at gmail.com> wrote: > > > > > Yeah I ported evented mongrel to run on packet> it does run and is > > faster than threaded mongrel, not quite as fast as event machine > > evented mongrel. > > > > The one problem is that the first request after server boot hangs but > > then all requests after that are fine. I will continue some more work > > on this. I think it would be nice to provide this as official mongrel > > *opt in* functionality once it''s all worked out. > > There''s several problems with Packet''s code, which I outlined for Evan over IRC earlier today: > > 1) It has EM code in it with the same GPL boilerplate. No GPL allowed as that will infect it with the viral license and open the door to malicious legal actions. > 2) You rewind the data stream in your mongrel code while the parser can handle incremental parsing. > 3) There''s several places where the code takes input from userland and embeds it in either an unpack or a regex thus allowing for userland format string attacks. > 4) There''s quite a lot of dubious stuff going on, like using activesupport, adding weird class attribute accessors via class eval, and just other bad code all around. > > That''s just in about 10 minutes of browsing the source. If I can find that much wrong with it that quick, then it still needs lots of work. First and foremost is the GPL though. It''s a no-go if it has viral licensing and just borrows code from other projects that has GPL. >Zed, There are two files which are there from eventmachine, deferable.rb and buftok.rb. Heck, there are just libs for aiding users. Packet doesn''t depend on activesupport, It did depend initially, but i removed that thing altogether. I know, many people don''t like, modifying core classes, and hence i am going to add them in helpers and it can potentially wreck havoc with other user code. I fully understand that. But lets see, how many methods were added to core classes: blank? nothing? #=> not needed classify #=> needed,but can be replaced with helper methods clean! => not needed iattr_accessor => needed deep_copy => not needed metaclass => needed iattr_accessor can''t be removed, because it adds attribute accessors around class intance variables. If you see, its quite useful thing. Since, class instance attributes aren''t shared across inheritance chain. It sure as hell needs work, whats more, this is my first ever public gem. Regarding licensing issues i don''t have much to say. Code is there, take it or leave it. But I do not understand, packet is dual licensed, so effectively one can use it under Ruby license and forget the fact that its under GPL too, because choice of license is left to the user. Also, mongrel itself is under GPL2, so how come two code bases, which are both under GPL can''t use each others code? I am missing here something important .fetch me Eben. This is sure funny. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
On Thu, 22 Nov 2007 14:00:58 +0530 hemant <gethemant at gmail.com> wrote:> Zed, > > There are two files which are there from eventmachine, deferable.rb > and buftok.rb. Heck, there are just libs for aiding users. > > Packet doesn''t depend on activesupport, It did depend initially, but i > removed that thing altogether.There was a comment at the top of a few files, like I said, 10 minutes cursory glance.> I know, many people don''t like, > modifying core classes, and hence i am going to add them in helpers > and it can potentially wreck havoc with other user code. I fully > understand that. But lets see, how many methods were added to core > classes:The issue isn''t so much hacking the core classes, but rather that the primary project that would use your stuff (Rails) already does this. What happens when they change their monkey patching to be slightly different from your''s? That''ll cause incompatibilities, and since Ruby''s open classes and mixins don''t provide any warnings or versioning in this case of clashing-hackery you''d be screwing all the people who use your stuff. It also would mess with just about any project that doesn''t use or want to use Rails. What about the folks using Facets? I''m sure there''s API differences in many of the monkey patching you do, Facets does, and Rails does. In general, when you write a low level library like Packet that has to coexist with lots of other bad code, you have to keep it clean and pristine with a minimal of evil.> iattr_accessor can''t be removed, because it adds attribute accessors > around class intance variables. If you see, its quite useful thing. > Since, class instance attributes aren''t shared across inheritance > chain.Or, you can just design it to not need that. When I looked at it first thing I thought was it screamed of over design and cleverness, which just doesn''t work in a project that has to coexist. Read above for more reasons why extending the base interactions of Ruby in your library is really a bad idea.> > It sure as hell needs work, whats more, this is my first ever public gem.Yep, I get that, and my comments are no slight to you personally. But, if you ever want it to be adopted, then take my advice and stop doing fancy stuff. My comments were also more for the Mongrel team since they went rushing to your fresh gem too quickly. As I said, if a quick 10 minute glance can give me that many warning signs then it''s not ready for use.> Regarding licensing issues i don''t have much to say. Code is there, > take it or leave it. But I do not understand, packet is dual licensed, > so effectively one can use it under Ruby license and forget the fact > that its under GPL too, because choice of license is left to the user.You''re right, I missed that the EM code iss also licensed under the Ruby license and GPL2 similar to Mongrel. But, a quick clarification:> Also, mongrel itself is under GPL2, so how come two code bases, which > are both under GPL can''t use each others code? I am missing here > something important .fetch me Eben. This is sure funny.No, you''re mistaken there, here''s the line that mentions the GPL: "You can redistribute it and/or modify it under either the terms of the GPL2 or the conditions below:" This isn''t saying it''s licensed under GPL2, it''s saying you can use either GPL2 -OR- the regular license. This is purely so that GPL purists can use the project, and everyone can not use the GPL if they want. It does NOT say that you have to use the GPL. So for licensing you''re good, but watch out for it. When you start borrowing code from other people you can get into trouble if they suddenly change their license, decide to interpret it differently, or just get pissy about how you use it. The rest of my comments still stand though. Keep working on Packet, but my suggestion is for you to go back and make it cleaner, smaller, include less external code, rely on less, and don''t do monkey patching so much. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Thu, 2007-11-22 at 13:10 -0500, Zed A. Shaw wrote:> On Thu, 22 Nov 2007 14:00:58 +0530 > hemant <gethemant at gmail.com> wrote:<snip where zed agreed>> The issue isn''t so much hacking the core classes, but rather that the primary project that would use your stuff (Rails) already does this. What happens when they change their monkey patching to be slightly different from your''s? That''ll cause incompatibilities, and since Ruby''s open classes and mixins don''t provide any warnings or versioning in this case of clashing-hackery you''d be screwing all the people who use your stuff. > > It also would mess with just about any project that doesn''t use or want to use Rails. What about the folks using Facets? I''m sure there''s API differences in many of the monkey patching you do, Facets does, and Rails does. > > In general, when you write a low level library like Packet that has to coexist with lots of other bad code, you have to keep it clean and pristine with a minimal of evil. > > Or, you can just design it to not need that. When I looked at it first thing I thought was it screamed of over design and cleverness, which just doesn''t work in a project that has to coexist. Read above for more reasons why extending the base interactions of Ruby in your library is really a bad idea. > > Yep, I get that, and my comments are no slight to you personally. But, if you ever want it to be adopted, then take my advice and stop doing fancy stuff. My comments were also more for the Mongrel team since they went rushing to your fresh gem too quickly. As I said, if a quick 10 minute glance can give me that many warning signs then it''s not ready for use.Ok zed, its my first gem and that doesn''t mean that its of low quality. Its already being used in couple of my internal company projects. Its being used in backgroundrb.And I am coding/using it a lot. In a nutshell, its not offspring of some arm chair design thingy. I needed it and I coded it. Why one writes open/free software? The main incentive is ( for me anyways ), so as people use it and generally original coder feels good about it. So, I do intend to make it possible to run mongrel on top of packet. But I am just adding 5 methods to core classes man, they are not big time design thingies, they can be easily removed. Packet doesn''t depend on those 5 methods.> So for licensing you''re good, but watch out for it. When you start borrowing code from other people you can get into trouble if they suddenly change their license, decide to interpret it differently, or just get pissy about how you use it.Good to get this cleared anyways.But its not like Oracle, taking code from RHEL. The two files that has been imported from EM, are imported and done for. One can change the license and whatever shit, I am not affected by that. Heck, i don''t even need those damn classes, they are mostly used by user level code, packet itself doesn''t use it. And they are also dual licensed under GPL2 and Ruby.> > The rest of my comments still stand though. Keep working on Packet, but my suggestion is for you to go back and make it cleaner, smaller, include less external code, rely on less, and don''t do monkey patching so much.Again, Zed, 5 methods. There is not so much of monkey patching as you mention. And I am trying to make it as clean and lean as possible. Look into code, send some patches if you feel something is dirty or can be improved.
On Fri, 23 Nov 2007 00:05:27 +0530 hemant kumar <gethemant at gmail.com> wrote: <snip>> > Yep, I get that, and my comments are no slight to you personally. But, if you ever want it to be adopted, then take my advice and stop doing fancy stuff. My comments were also more for the Mongrel team since they went rushing to your fresh gem too quickly. As I said, if a quick 10 minute glance can give me that many warning signs then it''s not ready for use. > > Ok zed, its my first gem and that doesn''t mean that its of low quality. > Its already being used in couple of my internal company projects. Its > being used in backgroundrb.And I am coding/using it a lot. In a > nutshell, its not offspring of some arm chair design thingy. I needed it > and I coded it.Well, actually I can go even further and give you more advice on how to improve it, but you seem more interested in defending your choices rather than listening. Good luck on it then.> Why one writes open/free software? The main incentive is ( for me > anyways ), so as people use it and generally original coder feels good > about it. So, I do intend to make it possible to run mongrel on top of > packet. But I am just adding 5 methods to core classes man, they are not > big time design thingies, they can be easily removed. Packet doesn''t > depend on those 5 methods.Another reason you release code is so that people can give you feedback on it. The second you put it out there it''s open for criticism, which is a good thing and you shouldn''t get offended by it. I never said "Hemant is a shitty coder." I said, "Hemant''s Packet isn''t that great, don''t use it yet, here''s exactly why." Once you understand the difference between the two you''ll be able to take criticism of your code much better. It also means that you have room to improve, and you just have to keep hacking on it. Rather than get upset, make it better. <snip>> > > > The rest of my comments still stand though. Keep working on Packet, but my suggestion is for you to go back and make it cleaner, smaller, include less external code, rely on less, and don''t do monkey patching so much. > > Again, Zed, 5 methods. There is not so much of monkey patching as you > mention. And I am trying to make it as clean and lean as possible. > Look into code, send some patches if you feel something is dirty or can > be improved.You are not reading carefully so I''ll break it down a little simpler, and then hopefully you''ll understand. After that, you''re on your own. I don''t throw pearls before swine. 1) Rails has these same or similar monkey patches. 2) Ruby has no way to version or select which monkey patch to use, and doesn''t warn you. 3) Ruby''s primary rule is Principle Of Least Surprise. 4) If you have your monkey patches in a system running Rails (which will happen under Mongrel) then your methods will clash with Rails'' methods. SURPRISE! 5) If you have your monkey patches in a system NOT RAILS then your methods will piss people off because SURPRISE! they aren''t expected. 6) If Rails changes the signature or behavior of their methods then your''s will override and people''s code will break. 7) When people''s code blows up, they''ll have no idea where the offending methods are coming from: Packet, Mongrel, Rails, Facets, Og, Nitro, Camping, Merb, Sinatra, or their own code. **) They are not needed and the benefit does not outweigh the disadvantage given above. Same goes for your class attribute stuff. It''s unexpected in a library that low level. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/