Ok I''m trying to figure out the best way to structure a server
application. Part of my problem is that I''m fairly new to ruby. For
each request to the server here is the basic workflow:
- parse request string
- Make database call
- format request for the following https POST.
- perform https POST to another server and wait for response
- do some text formatting mixed in with 2 other database calls.
- return response to client
I''d rather not just run everything in one big #defer. I''m
also trying
to figure out the cleanest way to do things like executing methods
within procs, which just doesnt'' feel right. There is too much code
in Trans to just put it all in the block, which is why I need to call
a method from the block. Is the following good form or is there
another way?
def line_received(line)
start = proc {
p = Trans.new
p.vital(line)
}
stop = proc {|result|
send_line "Result: #{result}"
}
EventMachine.defer( start, stop )
end
Also, I''d like to know if Deferrable works like I think it does. If I
create a class that uses Deferrable for the purpose of making an https
post, I can set a proc as a callback which will fire when I set the
status to succeed right? So I can use Deferrable to handle the post
instead of having to run it in a thread via #defer? Am I on the right
track here?
Got your message, will respond as soon as I get a minute to think about it. One thing you didn''t make clear is how will this application get used? Are you going to publish a server protocol that clients will use? On 8/8/06, snacktime <snacktime at gmail.com> wrote:> > Ok I''m trying to figure out the best way to structure a server > application. Part of my problem is that I''m fairly new to ruby. For > each request to the server here is the basic workflow: > > - parse request string > - Make database call > - format request for the following https POST. > - perform https POST to another server and wait for response > - do some text formatting mixed in with 2 other database calls. > - return response to client > > I''d rather not just run everything in one big #defer. I''m also trying > to figure out the cleanest way to do things like executing methods > within procs, which just doesnt'' feel right. There is too much code > in Trans to just put it all in the block, which is why I need to call > a method from the block. Is the following good form or is there > another way? > > def line_received(line) > start = proc { > p = Trans.new > p.vital(line) > } > > stop = proc {|result| > send_line "Result: #{result}" > } > > EventMachine.defer( start, stop ) > end > > Also, I''d like to know if Deferrable works like I think it does. If I > create a class that uses Deferrable for the purpose of making an https > post, I can set a proc as a callback which will fire when I set the > status to succeed right? So I can use Deferrable to handle the post > instead of having to run it in a thread via #defer? Am I on the right > track here? > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20060809/6d1b5108/attachment.html
It''s an application to process credit card transactions with processing networks. Not the online payment gateways but the networks that the payment gateways connect to such as Vital, Firstdata, Paymentech, etc.. There is just one protocol for the clients and not much information is sent. card number/expiration, amount, and address/cvv. I stole your netstrings code and I think I will use that. Each processing network has it''s own protocol. Most of them wrap their protocol in an https post. Vital/Firsdata use fixed length fields, Paymentech is xml. Those the 3 networks I am familiar with so I will start with them. So basically a client connects and sends the request, then the server connects to the gateway, gets the response, and then sends a response to the client. Clients should be able to send multiple requests in one connection, and can send a unique id with the request to match with the response, since the responses might not come back in the order they were sent. There will be 1-3 calls to the database for each request, depending on the type of request. Right now I have separate perl apps for all of these networks in different languages or platforms. I want to consolidate everything into one application.
Ok, understood. Will respond with some suggestions when I get a moment. On 8/9/06, snacktime <snacktime at gmail.com> wrote:> It''s an application to process credit card transactions with > processing networks. Not the online payment gateways but the networks > that the payment gateways connect to such as Vital, Firstdata, > Paymentech, etc.. There is just one protocol for the clients and not > much information is sent. card number/expiration, amount, and > address/cvv. I stole your netstrings code and I think I will use > that. Each processing network has it''s own protocol. Most of them > wrap their protocol in an https post. Vital/Firsdata use fixed > length fields, Paymentech is xml. Those the 3 networks I am familiar > with so I will start with them. > > So basically a client connects and sends the request, then the server > connects to the gateway, gets the response, and then sends a response > to the client. Clients should be able to send multiple requests in > one connection, and can send a unique id with the request to match > with the response, since the responses might not come back in the > order they were sent. There will be 1-3 calls to the database for > each request, depending on the type of request. > > Right now I have separate perl apps for all of these networks in > different languages or platforms. I want to consolidate everything > into one application. > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >