On 3 sep, 18:08, Rick <[email protected]> wrote: > My point in bringing in C was that the tools you choose are those that > can do the job. If you have a real time requirement (something with > msecs response) you won't be happy with interpreted code exchanging > messages via email. However, if what you've been given is more on the > order of "use Ruby on Rails and make this as fast as possible" then > you can certainly get the job done.
What I was given was: - I'd like you to develop an app in PHP - When x happens, an e-mail needs to be sent out as fast as possible and every millisecond counts. At that moment I mentioned Rails because I had no clue on what this app needed to do and I just love Rails and want to limit the time I spend coding PHP scripts. However, now I know the details, I think it might be important to look into other programming languages and/or frameworks. Of course, cost is an issue and it's an application for which I could probably have a v0.1 ready in under 20 hours. If I need to learn a new language, though, I might be taking alot longer. I know, that's his problem, but I want to offer a set of possibilities and it's for him to decide what's most important. > > The real tradeoff here is that to achieve real speed you must > invariably give up flexibility. Even though you could write a hard > drive controller in Ruby I doubt you would be satisfied with the > result. > > I would recommend that you spend some time defining what you are > trying to do and get requirements set for the areas of your > application in which performance is critical. You should have real > numbers here - or agreement with your user that "as fast as possible" > is adequate. The numbers aren't disclosed. We will need to develop the application, cross our fingers and hope it's fast enough. It could easily be that it's not possible and our e-mail messages arrive too late every time. That's why I need to be sure that what we develop is the best we can come up with within the budget. If C is the way to go, I will offer that possibility. However, I'm quite sure I will need twice as long in C and might have less time left for fine-tuning. > > Take a look at SNMP as a mechanism for collecting data from remote > systems - you might look at MRTG for example. Quite often you can > partition the time sensitive portion out from the reporting portion. > You could, for example, build status logs to report out when all is > running in a pre-defined "good" way and make a nice web view that's > driven from the logs. You obviously need to develop a strategy for > reporting and responding to the alert and alarm states that populate > the "not good" space. This is the place where time can be critical. What you're saying might be very important. I know the kind of information I'm looking for, so if I can assign the highest priority to the incoming data that contains this information, that could help. The third time-critical application will actually be designed so that when the time-critical stuff comes up, it drops everything it does and sends out the e-mail. > > So go for it - sounds like fun. At least it's very interesting! It will be fun when I figure it out, - if- I figure it out ;) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
