| Author |
Message |
|
| Guest |
 Posted: Fri Sep 28, 2007 7:11 am |
 |
|
|
Guest
|
|
| Back to top |
|
| alexis |
| Posted: Fri Sep 28, 2007 2:19 pm |
|
|
|
User
Joined: 06 Sep 2007
Posts: 80
Location: London
|
|
| Back to top |
  
|
| Guest |
| Posted: Sat Sep 29, 2007 1:12 am |
|
|
|
Guest
|
----- "Alexis Richardson" <alexis.richardson@cohesiveft.com> wrote:
> On 9/28/07, Tom Samplonius <tom@samplonius.org> wrote:
> > > Does that make any sense?
> >
> > While linking a C library to PHP would do the trick, introducing a
> new module API into PHP is definitely non-trivial.
> >
> > I was hoping that there might be a native PHP library. Isn't the
> Ruby library pure Ruby? AMQP is a binary protocol, so a native PHP is
> a bit hard, but appears doable.
>
> OK. You are right about the Ruby client. I'm afraid there is no
> native PHP client. What are your thoughts on the pros and cons of
> doing one? How useful would it be to you?
Well, what is challenging about the PHP environment, is any long running tasks. That is anything that can't be done during the http request/response cycle. You will want to have a background worker handle any processing that takes 10+ seconds. So the web handler can just put a message in the queue, and a background worker can process it.
Also, doing critical steps in a web response code isn't exactly great either, because the Stop button issues. In some cases, a stop, will cause the web server to stop the PHP interpreter, possible leaving various things in a unknown state. Particularly if your PHP script is talking to an external web service. It would be much better to have any critical processing done by a background worker, which has a more stable execution environment.
An another issue, is serialization. I have a remote control hardware device connected to a serial port. Only one application can be talking to it at once. A message queue provides an ideal serialization mechanism.
> alexis
>
>
>
> --
> Alexis Richardson
> +44 20 7617 7339 (UK)
> +44 77 9865 2911 (cell)
> +1 650 206 2517 (US)
Tom
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| alexis |
| Posted: Sun Sep 30, 2007 2:47 pm |
|
|
|
User
Joined: 06 Sep 2007
Posts: 80
Location: London
|
Tom
Thanks for describing the use cases. Knowing nothing about PHP, I
would never have realised the server workflow could benefit from
messaging in this way.
I've been scratching my head trying to think of a way to help. One
thought was to combine one of the C clients (say, OpenAMQ, which is
BSD licensed iirc), with the WSF/PHP plug-in from WSO2, which loads
processors for, eg SOAP and WS-RM, to a PHP web server. There is
enough family resemblance between WS and REST style invocations, and
AMQP, that the source code might help you. You can get it from here:
http://dist.wso2.org/products/wsf/php/1.0.0/
Feel free to flame me if this is a completely bogus suggestion.
Thoughts?
alexis
On 9/29/07, Tom Samplonius <tom@samplonius.org> wrote:
>
> Well, what is challenging about the PHP environment, is any long running tasks. That is anything that can't be done during the http request/response cycle. You will want to have a background worker handle any processing that takes 10+ seconds. So the web handler can just put a message in the queue, and a background worker can process it.
>
> Also, doing critical steps in a web response code isn't exactly great either, because the Stop button issues. In some cases, a stop, will cause the web server to stop the PHP interpreter, possible leaving various things in a unknown state. Particularly if your PHP script is talking to an external web service. It would be much better to have any critical processing done by a background worker, which has a more stable execution environment.
>
> An another issue, is serialization. I have a remote control hardware device connected to a serial port. Only one application can be talking to it at once. A message queue provides an ideal serialization mechanism.
>
> > alexis
> >
> >
> >
> > --
> > Alexis Richardson
> > +44 20 7617 7339 (UK)
> > +44 77 9865 2911 (cell)
> > +1 650 206 2517 (US)
>
>
> Tom
>
--
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| tonyg |
| Posted: Tue Oct 02, 2007 9:12 am |
|
|
|
User
Joined: 07 Nov 2006
Posts: 199
|
Hi Tom,
Tom Samplonius wrote:
> Well, what is challenging about the PHP environment, is any long
> running tasks. That is anything that can't be done during the http
> request/response cycle.
This lines up nicely with your other thread, about RESTful access to
AMQP. Creating a full AMQP connection for every PHP script invocation
seems very heavy - it's not only a full TCP connection, but it's several
roundtrips between the client and broker. Perhaps a lighter RESTful
HTTP-to-AMQP portal would work better: PHP scripts would both submit and
retrieve messages via AMQP-over-HTTP...
I'll have to dig out my sketchy notes on what a good AMQP-over-HTTP
would look like.
Regards,
Tony
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
