Will Rails be able to do this -fast- ?

jhaagmans wrote:

Um...no. �I'm not trying to pry into your requirements, but I *am* telling you that your requirements must make sense, or else your project is doomed.

You are being asked to build an F-16 with your choice of a bicycle or a moped as engine. �Oh, and it has to have a fuel efficiency of 30 MPG, and don't spend too much time developing it. �Your requirements do not make sense.

I'm not bound to using PHP, Ruby or anything. I'm just bound to a certain budget which limits my possibilities. And that will limit the speed of the application. It will be a matter of as fast as possible though, which is why I want to do this using the right tool.

That makes a lot more sense.

The requirements make sense. At least, to me they do. He also has his reasons to believe this can be done on a low budget. And the thing is, I don't doubt it.

I do. At least, I doubt that it can be done on a low budget by *you*. I don't mean that as an insult, just that based on the questions you've asked in this thread, your expertise seems to be elsewhere, so it will take you more time and effort for this project than it would someone who does this kind of stuff all the time.

The goal of the application is to increase the success rate of my client's business. Say it's at 1:1000 right now. If I can get it up to 1:500 (which is a matter of speed in this case) I will have myself one happy client. However, if I can get it up to 1:400, I will have an even happier client. If I exceed the budget by more than say, 10%, I will have an angry client. So I need to increase the speed by as much as possible within the budget.

In other words, your client will not be willing to pay that extra 10% even if he gets an extra 20% beyond what he was promised in success increase. Right? If that's so, dump the client. He wants the world on a shoestring.

So again I ask you to stop questioning the why.

I hear this from clients too from time to time. It is almost always bad advice. If you can't say "*why* do you need this" to your client, then you cannot help your client optimally. Requirements are not articles of faith.

If it's not possible, I will find that out and so will he. But I do want to give this an honest chance.

Then ask questions and listen to the advice you've been getting in this thread. Better yet, find a TCP/IP/real-time systems weenie to work with. Right now, this project has "Daily WTF" written all over it -- and that will result in a *very* angry client.

Best,

Thanks Marnen.

But again, I know about the why. And I can ask my client those questions. I'm just saying -you- shouldn't, simply because I can't tell you. Everyone has been very helpful as to how I might be able to pull this off and that's what I wanted from this. None of my projects have thusfar resulted in a big traincrash and I highly doubt this one will.

I wonder if it is the _sending_ of the email that is important here. Perhaps the time at which it is received is not important.

Colin

Thanks Colin,

I wonder if it is the _sending_ of the email that is important here. Perhaps the time at which it is received is not important.

It's actually something in between. The moment at which the e-mail leaves our machine is important to me. After that we will have to accept that it might get caught up somewhere. At least, I think we will... If the remote machine queues it up, we don't know what happens, we're not sure how the remote machine handles messages that were delayed by its own infrastructure. But I will have to do some trial and error there.

jhaagmans wrote:

Thanks Colin,

I wonder if it is the _sending_ of the email that is important here. Perhaps the time at which it is received is not important.

It's actually something in between. The moment at which the e-mail leaves our machine is important to me. After that we will have to accept that it might get caught up somewhere. At least, I think we will... If the remote machine queues it up, we don't know what happens, we're not sure how the remote machine handles messages that were delayed by its own infrastructure. But I will have to do some trial and error there.

You know that just about everything email-wise can be falsified, including timestamps, right?

You know that just about everything email-wise can be falsified, including timestamps, right?

I do :slight_smile:

However, I doubt that timestamps matter for the remote machine. I think everything is processed in the order it got in. But again, we'll need to find that out. I can't be sure about it.

jhaagmans wrote:

You know that just about everything email-wise can be falsified, including timestamps, right?

I do :slight_smile:

However, I doubt that timestamps matter for the remote machine. I think everything is processed in the order it got in. But again, we'll need to find that out. I can't be sure about it.

Can you ask the folks who control the recipient machine? The less guessing you have to do, the better.

Best,

jhaagmans wrote:

Thanks Marnen.

But again, I know about the why. And I can ask my client those questions.

Good

I'm just saying -you- shouldn't, simply because I can't tell you.

You don't get it, then. I'm not asking because I want the answers; I'm asking to make sure *you* can formulate the answers. Apparently you can; if so, great.

Everyone has been very helpful as to how I might be able to pull this off and that's what I wanted from this. None of my projects have thusfar resulted in a big traincrash and I highly doubt this one will.

I hate to be a pessimist, but I cannot see how it will be anything but. You're trying to implement a real-time low-latency messaging queue over e-mail, and you're trying to do it on a low budget. Moreover, your expertise seems to be in a different area, so you'll be spending lots of that low budget on research. I suppose it's possible to pull these chestnuts out of the fire, but suffice it to say that I'm really worried.

BTW, is the machine on the receiving end actually checking e-mail often enough that every millisecond is significant? I would doubt it, and if not, then this whole project is a waste of time.

Best,

BTW, is the machine on the receiving end actually checking e-mail often enough that every millisecond is significant? I would doubt it, and if not, then this whole project is a waste of time.

Actually, Marnen, the smart thing to do here is not to rely on a client but to set up a forwarding rule on the mail server itself so that the email ends up someplace which is actively waiting for it. Implementation to be determined :wink:

Hi,

Sorry I am realy new in rails (and not good in active English, too
*g*). I need to administrate users with two roles. I have seen Aegis
and it seems to be very good for my needs - but as long as I haven't found the clue, I can give there every user
only one role.

Do you know another plugin, where I can static (and centralized)
define two types of roles (I don't want to lose performance in having
an additional table in the database with many accesses) or are the
only two possibilities to write it myselft or to customize Aegis and
will need to make this anytime they will release an update of Aegis?

Thank you very much, Bente

Aldric Giacomoni wrote:

BTW, is the machine on the receiving end actually checking e-mail often enough that every millisecond is significant? I would doubt it, and if not, then this whole project is a waste of time.

Actually, Marnen, the smart thing to do here is not to rely on a client but to set up a forwarding rule on the mail server itself so that the email ends up someplace which is actively waiting for it. Implementation to be determined :wink:

Except that Jaap already said he doesn't control the recipient.

Best,

Can you ask the folks who control the recipient machine? The less guessing you have to do, the better.

That's obviously not possible, I'm not guessing when I could easily ask.

I hate to be a pessimist, but I cannot see how it will be anything but. You're trying to implement a real-time low-latency messaging queue over e-mail, and you're trying to do it on a low budget. Moreover, your expertise seems to be in a different area, so you'll be spending lots of that low budget on research. I suppose it's possible to pull these chestnuts out of the fire, but suffice it to say that I'm really worried.

You shouldn't worry about my project as much as you do. The app is not as complicated as it may seem and my only worry at this point is to get the e-mail out as fast as possible. But that can also be done at a later time, because the automation of this process will increase business success dramatically. However, it would be nice to do it right from the start.

BTW, is the machine on the receiving end actually checking e-mail often enough that every millisecond is significant? I would doubt it, and if not, then this whole project is a waste of time.

Again, I can't be sure about this, but I think e-mails received at this address are piped through to an application. I know, it's lame and it sure as hell isn't efficient, but I can't change this. At least I know our position in the queue is more important than the actual handling time on the remote server.

Ah, right, it is where your email appears in the receivers queue relative to everybody else's emails that matters. That is why the processing time at the receiver is not important. It is a matter of getting your bid in before others that matters.

Colin

Ah, right, it is where your email appears in the receivers queue relative to everybody else's emails that matters. That is why the processing time at the receiver is not important. It is a matter of getting your bid in before others that matters.

Something like that, yes :slight_smile: Even though there are no real others. Cryptic, ey? :wink:

Anyway, thanks for all the help, I'm writing my recommendations as we speak and probably start work next week. I really appreciate you all taking the time to help me :slight_smile:

Keep us in the loop. Whatever happens, I smell a useful article here on whatever tips/tricks/pitfalls you discover. You are dealing with various third parties and various protocols in a time sensitive application, so whatever you find will be interesting, even if you have to mock up the actual material (since you can't seem to talk about specifics this is understandable) I think it would still be interesting to read.

jhaagmans wrote: