Hey all I am working with a technology standard (specific to the commercial print industry) by which each element within the workflow has bi- directional HTTP messaging. As each side needs a http server, I thought I could either: a) use a gem plugin to modify the behavior of mongrel b) subclass Mongrel::HttpHandler In short, its xml messaging between two points; each with a HTTP client and HTTP server, a sort of xml conversation. I was thinking that I could leverage mongrel to do this...? I have no idea which method would work best (I am thinking the subclass route?) but I was thinking I could set up some kind of system to parse/handle (most likely with libxml-ruby) the incoming xml requests then serve back the correct response? Any suggestions / comments are welcomed as I am quite in the dark with this one Cheers Tim
I think the Mongrel gem you''d end up writing would likely subclass its HttpHandler anyway, so I think the options might be one and the same. I might first just try some built in rails stuff unless you''re worried about the speed. On 7/24/07, Tim Perrett <hello at timperrett.com> wrote:> Hey all > > I am working with a technology standard (specific to the commercial > print industry) by which each element within the workflow has bi- > directional HTTP messaging. As each side needs a http server, I > thought I could either: > > a) use a gem plugin to modify the behavior of mongrel > b) subclass Mongrel::HttpHandler > > In short, its xml messaging between two points; each with a HTTP > client and HTTP server, a sort of xml conversation. I was thinking > that I could leverage mongrel to do this...? I have no idea which > method would work best (I am thinking the subclass route?) but I was > thinking I could set up some kind of system to parse/handle (most > likely with libxml-ruby) the incoming xml requests then serve back > the correct response? > > Any suggestions / comments are welcomed as I am quite in the dark > with this one > > Cheers > > Tim > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >
I''d strongly recommend using Camping over Rails. We wrote a similar application (RubyCAS-Server -- the CAS protocol uses conversational HTTP), and Camping was definitely the way to go. The main problem with Rails is that it''s not asynchronous. Rails can''t talk and listen at the same time, at least not within the same transaction. You might be able to get around this, but you''ll probably find yourself doing all kinds of gymnastics. Camping doesn''t have this problem. It''s much better suited for these kinds of faceless apps anyway, since it''s not weighed down by all the UI niceties you get with Rails. Jameson Watts wrote:> I think the Mongrel gem you''d end up writing would likely subclass its > HttpHandler anyway, so I think the options might be one and the same. > I might first just try some built in rails stuff unless you''re worried > about the speed. > > On 7/24/07, Tim Perrett <hello at timperrett.com> wrote: > >> Hey all >> >> I am working with a technology standard (specific to the commercial >> print industry) by which each element within the workflow has bi- >> directional HTTP messaging. As each side needs a http server, I >> thought I could either: >> >> a) use a gem plugin to modify the behavior of mongrel >> b) subclass Mongrel::HttpHandler >> >> In short, its xml messaging between two points; each with a HTTP >> client and HTTP server, a sort of xml conversation. I was thinking >> that I could leverage mongrel to do this...? I have no idea which >> method would work best (I am thinking the subclass route?) but I was >> thinking I could set up some kind of system to parse/handle (most >> likely with libxml-ruby) the incoming xml requests then serve back >> the correct response? >> >> Any suggestions / comments are welcomed as I am quite in the dark >> with this one >> >> Cheers >> >> Tim >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> >> > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. Le contenu du pr''esent courriel est privil''egi''e, confidentiel et soumis `a des droits d''auteur. Il est interdit de l''utiliser ou de le divulguer sans autorisation.
Ahh good stuff - cheers for the tip about camping! I took a brief look at the cas server, and you guys have implemented with mongrel (and others) by subclassing from what I can see? What is it that camping does for you by the way (in the context of cas- server)? (apologies for the stupid question but ive never used camping or heard of it lol) Cheers all Tim On 24 Jul 2007, at 16:39, Matt Zukowski wrote:> I''d strongly recommend using Camping over Rails. We wrote a similar > application (RubyCAS-Server -- the CAS protocol uses conversational > HTTP), and Camping was definitely the way to go. The main problem with > Rails is that it''s not asynchronous. Rails can''t talk and listen at > the > same time, at least not within the same transaction. You might be able > to get around this, but you''ll probably find yourself doing all > kinds of > gymnastics. Camping doesn''t have this problem. It''s much better suited > for these kinds of faceless apps anyway, since it''s not weighed > down by > all the UI niceties you get with Rails.
Camping basically gives you a clean and simple MVC (Model-View-Controller) platform. Same as Rails, but a lot more light-weight and, in my opinion, better suited for faceless daemons like the one you''re writing. In terms of the niceties you get with Camping -- for one, you can easily map your URLs to specific methods. So an HTTP POST to URL "/foo?id=9" can be mapped to method "post(id)" in module "Foo". There''s also a nice view component that lets you render templates using Markaby -- ruby markup that generates XML..... but this is all probably beyond the scope of this newsgroup. Have a look at http://camping.rubyforge.org/files/README.html Tim Perrett wrote:> Ahh good stuff - cheers for the tip about camping! > I took a brief look at the cas server, and you guys have implemented > with mongrel (and others) by subclassing from what I can see? What is > it that camping does for you by the way (in the context of cas- > server)? (apologies for the stupid question but ive never used > camping or heard of it lol) > > Cheers all > > Tim > > > On 24 Jul 2007, at 16:39, Matt Zukowski wrote: > > >> I''d strongly recommend using Camping over Rails. We wrote a similar >> application (RubyCAS-Server -- the CAS protocol uses conversational >> HTTP), and Camping was definitely the way to go. The main problem with >> Rails is that it''s not asynchronous. Rails can''t talk and listen at >> the >> same time, at least not within the same transaction. You might be able >> to get around this, but you''ll probably find yourself doing all >> kinds of >> gymnastics. Camping doesn''t have this problem. It''s much better suited >> for these kinds of faceless apps anyway, since it''s not weighed >> down by >> all the UI niceties you get with Rails. >> > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. Le contenu du pr''esent courriel est privil''egi''e, confidentiel et soumis `a des droits d''auteur. Il est interdit de l''utiliser ou de le divulguer sans autorisation.