Topics covered on Nov meeting

[JasonOng]

Hi rubyists

For the benefit of the unfortunate individuals who couldn't make it
for the last meeting, here's a brief of what was discussed/presented.

1) Presentation 1: OAuth4r by Choonkeat

2) Presentation 2: Sinatra framework by Deepak

3) Light discussions

- Using Monngrel to handle multithreading in rails
- Controllers/model/route design for RESTful interface
- Continuous Http connections in Rails

Hope I haven't missed out anything. Wish I can do something like a
minutes of the presentations covered. Maybe all of us who were present
there can chip in? Good way to take the discussions offIine too.

Cheers

[choonkeat]

For those who missed it and who likes slides, here are mine. But for those who prefer watching somebody talk, this is a presso done by Leah Culver of Pownce

--
choonkeat

[Harish Mallipeddi]

Btw here are Leah's slides (if you don't want to watch the video):

http://www.slideshare.net/leahculver/oauth-open-api-authentication/

Actually the spec is not that hard to read - it's probably the first spec that I ever managed to read in a single sitting :)

Cheers,
Harish

--
Harish Mallipeddi
Software Engineer
Work: http://www.circos.com
Blog: http://poundbang.in
Mobile: (+65) 96976230
GTalk: harish.mallipeddi

[Deepak Jois]

Hi
Another topic that had come up for a brief while was Ajax and Comet. I just came across this post by Simon Willison which sheds more light on the matter.

http://simonwillison.net/2007/Dec/5/comet/

Deepak

[JasonOng]

Hello to those present at Nov's meeting.

Someone (sorry I didn't get your name) mentioned about keeping HTTP
connnections alive for a real-time stock app. Chanced upon this web
server Meteor built specifically for comet-style pushes. Then found
out that Rails have a Juggernaut plugin that does pushing via flash
socket. Just a post here in case you (that someone) haven't check them
out.

Meteor: http://meteorserver.org/demo/
Juggernaut: http://juggernaut.rubyforge.org/

Cheers.

[Harish Mallipeddi]

Thanks Jason and Deepak for your replies.

But in all these cases, they seem to be using an external comet (or push) server instead of using Rails/Django as-is.

[JasonOng]

Hi Harish (finally know yr name heh)

You might wanna check this out too.

http://thinkruby.org/2007/10/49

Thanks Deepak for the link!

Cheers.

On Dec 6, 10:06 am, "Harish Mallipeddi" <harish.mallipe...@gmail.com>
wrote:

> Thanks Jason and Deepak for your replies.
>
> But in all these cases, they seem to be using an external comet (or push)
> server instead of using Rails/Django as-is.
>

[choonkeat]

I haven't looked at the implementations, but regarding the "external comet server" architecture, the only downside seems to be deployment complexity, imho. And you only need to get that right once. Or perhaps I'm missing your concern

The upside however, is that your architecture is straight-forward to understand, and development model is simple - as in, you keep close to out-of-the box Rails / Django without relying on too much hack.

Btw this post abt Bayeux seems interesting.

Cheers
--
choonkeat

[Harish Mallipeddi]

Well there's nothing wrong with that approach and this is what I ended up doing at my previous company - building an external Python web server but of course I didn't go ahead and implement a full-scale protocol :) I was just being curious as to how you would keep a connection alive from inside a Rails/Django view.

Btw Bayeux is the protocol, cometd is the framework. The project is supported by Dojo Foundation which explains why Dojo has in-built support for it. More info: http://cometd.com/. If you think about it, this is basically an event/messaging server (sorta like running Jabber) except it uses JSON for encapsulating data and it understands the browser quirks that it has to get around in order to keep the connection persistent.

Cheers,
Harish

[JasonOng]

Hi Harish

Not sure if you came across this Rails + Mongrel only solution for
Comet.

http://adam.blogs.bitscribe.net/2007/05/08/comet-with-rails-mongrel/

Cheers.

On Dec 6, 11:08 pm, "Harish Mallipeddi" <harish.mallipe...@gmail.com>
wrote:

> Well there's nothing wrong with that approach and this is what I ended up
> doing at my previous company - building an external Python web server but of
> course I didn't go ahead and implement a full-scale protocol :) I was just
> being curious as to how you would keep a connection alive from inside a
> Rails/Django view.
>
> Btw Bayeux is the protocol, cometd is the framework. The project is
> supported by Dojo Foundation which explains why Dojo has in-built support
> for it. More info:http://cometd.com/. If you think about it, this is
> basically an event/messaging server (sorta like running Jabber) except it
> uses JSON for encapsulating data and it understands the browser quirks that
> it has to get around in order to keep the connection persistent.
>
> Cheers,
> Harish
>

> On Dec 6, 2007 11:11 AM, choonkeat <choonk...@gmail.com> wrote:
>
>
>
> > I haven't looked at the implementations, but regarding the "external comet
> > server" architecture, the only downside seems to be deployment complexity,
> > imho. And you only need to get that right once. Or perhaps I'm missing your
> > concern
>
> > The upside however, is that your architecture is straight-forward to
> > understand, and development model is simple - as in, you keep close to
> > out-of-the box Rails / Django without relying on too much hack.
>

> > Btw this post abt Bayeux <http://r9.sharedcopy.com/1d4qo1#shcp1> seems
> > interesting.
>
> > Cheers
> > --
> > choonkeat
>
> > On Dec 6, 2007 10:06 AM, Harish Mallipeddi < harish.mallipe...@gmail.com>

> > wrote:
>
> > > Thanks Jason and Deepak for your replies.
>
> > > But in all these cases, they seem to be using an external comet (or
> > > push) server instead of using Rails/Django as-is.
>

[choonkeat]

good find :-) mongrel handlers.. yummy. presso on mongrel [handlers] anyone?

--
choonkeat