Re: namespace request - PoCo::Server::MDP
On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: I'm in what I hope is final testing before releasing a public beta of a set of modules that act as POE components to provide Message Driven Perl services - in the vein of a JMS provider. The intent is that someone will be able to do something similar to # use POE; use POE::Component::Server::MDP::POEQueueProvider; Wow, that's long, and Provider seems to overlap with Server. POE::Component::MDP::QueueProvider still has some length to it, but it sounds a lot less redundant. I assume there will be a lot of modules below POE::Component::MDP. Any objections to the namespace? Better suggestions? Perl Messaging Service has already been rejected... ;-) Perl Queuing Runtime Server Thingy? :) -- Rocco Caputo - [EMAIL PROTECTED]
Re: namespace request - PoCo::Server::MDP
On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: use POE::Component::Server::MDP::POEQueueProvider; is a server really a component? wouldn't POE::Server::MDP make more sense?
Re: namespace request - PoCo::Server::MDP
On Sat, Aug 27, 2005 at 05:16:06PM -0400, Rocco Caputo wrote: On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: I'm in what I hope is final testing before releasing a public beta of a set of modules that act as POE components to provide Message Driven Perl services - in the vein of a JMS provider. The intent is that someone will be able to do something similar to # use POE; use POE::Component::Server::MDP::POEQueueProvider; Wow, that's long, and Provider seems to overlap with Server. POE::Component::MDP::QueueProvider still has some length to it, but it sounds a lot less redundant. I assume there will be a lot of modules below POE::Component::MDP. POE::Server::MessageBus POE::Component::MessageBus::Client ? -- Matt S Trout Specialists in perl consulting, web development, and Technical DirectorUNIX/Linux systems architecture and automation. Mail Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
Re: SMPP and POE
On Aug 26, 2005, at 12:40, Abhishek Jain wrote: Dear Friends, I have a task to do.I need to send SMS using SMPP protocol .It is a 'Application Layer TCP protocol'. I do understand POE but never had a chance to implement a protocol. Can anyone here suggest me how to do so , I mean how to create packets etc.I do have a document of SMPP available at www.smsforum.net http://www.smsforum.net/ .Also I would be using multi-tasking so Want to use POE. Creating packets is not hard. Your operating system takes care of all the layers below application for you. First you need to understand how applications transfer information. I recommend finding a simple protocol (for example POP3), reading the relavent documentation, and using telnet to interact with a server. SMPP may be simple enough, but I've never used it and can't recommend it either way. All stream protocols work the same. The sender translates structured data into a format that can be sent across a socket. The act of translating data like this is called serialization. The receiver parses inbound streams back into structured data it can use. POE::Filter classes have a generic interface to perform these actions so they can be plugged into client and server applications. Is the answer lies in that I will have to create a Filter or so. If yes give me a Hint and if possible a small demo. You can't begin to write a filter until you understand the protocol. If you don't know how an SMPP client and server talk to each other, then you can't begin to write one (or the other) yourself. There is already an implementation of SMPP via NET::SMPP but I am not sure that whether it is applicable for multitasking also. I need to create a client and a server . Anyone here having a clue or a tutorial Please tell me. I shall be very grateful. Aside from their constructors, filters have four methods: The two easiest are probably get_one_start() and get_pending(). get_one_start() places raw data from a socket into the filter's parsing buffer. get_pending() retrieves any unused data from the filter's parsing buffer. See the source for them in POE::Filter::Line; they're only two or three lines long. The put() method is next in line of difficulty. It takes one or more structured data packets and returns the same number of serialized data chunks, ready to be sent across a socket. It should be easy to write a put() method once you know how to perform the serialization for your protocol. get_one() is probably the hardest method to write. It parses data from the filter's parsing buffer, returning zero or more complete data structures. This performs the task commonly known as deserializing, thawing, or cooking. Your filter is done once you have written those four methods. The real work comes after that: Documenting, writing tests, and releasing your code on the CPAN. -- Rocco Caputo - [EMAIL PROTECTED]
Re: namespace request (combined reply)
On Sat, Aug 27, 2005 at 05:16:06PM -0400, Rocco Caputo wrote: On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: use POE::Component::Server::MDP::POEQueueProvider; Wow, that's long, and Provider seems to overlap with Server. POE::Component::MDP::QueueProvider still has some length to it, but it sounds a lot less redundant. I assume there will be a lot of modules below POE::Component::MDP. I'm happy to move up from Server. There will in fact be several different Providers, I have two now and will, I think, shortly do one for a Thread::Queue. So I can't really use QueueProvider for the one I showed, since they will all be queue providers. I could go with just POEProvider. But that might be redundant... Brevity should never fall before clarity except in the service of obfuscation. Well, maybe not never.. On Sat, Aug 27, 2005 at 05:16:06PM -0400, Rocco Caputo wrote: Any objections to the namespace? Better suggestions? Perl Messaging Service has already been rejected... ;-) Perl Queuing Runtime Server Thingy? :) Nahh. Then I'd have to build a UniversalVarientWorkingXample... :-) At 05:26 PM 8/27/2005, Erick Calder wrote: On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: use POE::Component::Server::MDP::POEQueueProvider; is a server really a component? wouldn't POE::Server::MDP make more sense? Well, I was working from Poco::Server::SimpleHTTP... Also, I didn't want to create POE::Server myself. Happy to do it if it seems appropriate. At 05:38 PM 8/27/2005, Matt S Trout wrote: POE::Server::MessageBus POE::Component::MessageBus::Client ? MessageBus might be a little bit reaching for me. A message bus, to me, is more than just access to a MOM layer. It's a combination of a MOM layer and a schema/protocol for the conversations that occur on it. You can't do SOA without a message bus (HTTP is *not* a messaging protocol, sorry!). Also, I'm working from the intention that my code is acting as a server to the user's code. So I don't want to call my code a client. Although the whole business does get messy - as particularly with the WebSphere MQ provider I have, my code can create both a 'server' connection and a 'client' connection (and boy that was a pain, given the DWIM behavior of the MQSeries perl modules). -Jeff
Re: namespace request - PoCo::Server::MDP
On Aug 27, 2005, at 17:26, Erick Calder wrote: On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: use POE::Component::Server::MDP::POEQueueProvider; is a server really a component? wouldn't POE::Server::MDP make more sense? As far as I know, applications don't need namespaces at all. If this is the case, why bother giving it a name at all? This gives me the opportunity to briefly discuss POE::Stage again. Source is browsable at http://thirdlobe.com/projects/poe-stage/ browser/trunk/ . It's a prototype base class for the next generation of POE component, solving a number of current problems that POE::Component has. 1. Long name. POE::Stage is shorter to type and easier to say, even if it's not nearly as descriptive. Suggestions welcome. 2. Inconsistent call signature. Event handlers receive two parameters: my ($self, $args) = @_;. $args is a hash reference with named parameters. You don't need to memorize the contents of ARG3 as it varies for each component's response. 3. Fiddling with $_[HEAP] to match response data with request contexts. POE::Stage uses powerful magic to make sure parts of $self are always relevant for the current request and/or response context an object currently is in. 4. Session-scoped resources. Thing of the past. POE::Stage's class- based event watchers are object-scoped, which is way easier to comprehend. 5. Others? I forget. It's been a while since I've poked at the project. If you have some time and inspiration, grab yourself a copy from the repository: svn co https://thirdlobe.com/svn/poe-stage/trunk . -- Rocco Caputo - [EMAIL PROTECTED]
Re: namespace request (combined reply)
On Aug 27, 2005, at 17:46, Jeff Lowrey wrote: On Sat, Aug 27, 2005 at 05:16:06PM -0400, Rocco Caputo wrote: On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: use POE::Component::Server::MDP::POEQueueProvider; Wow, that's long, and Provider seems to overlap with Server. POE::Component::MDP::QueueProvider still has some length to it, but it sounds a lot less redundant. I assume there will be a lot of modules below POE::Component::MDP. I'm happy to move up from Server. There will in fact be several different Providers, I have two now and will, I think, shortly do one for a Thread::Queue. So I can't really use QueueProvider for the one I showed, since they will all be queue providers. I could go with just POEProvider. But that might be redundant... Brevity should never fall before clarity except in the service of obfuscation. Well, maybe not never.. POE's role in MDP sounds more marginal as this thread continues. Maybe there should be a top-level MDP distribution, including MDP::QueueProvider::POE, MDP::QueueProvider::Thread, etc. If MDP is generic and expansive enough, the CPAN Gods may bless it with a top-level namespace grant. -- Rocco Caputo - [EMAIL PROTECTED]
