Language:
switch to room list switch to menu My folders
Go to page: First ... 22 23 24 25 [26] 27 28 29 30 ... Last
[#] Mon Mar 30 2009 11:29:08 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I love C++ more than all the others, but as far as I know fastcgi is

still the only way to avoid having to fork a process, and that's still

kinda lame.

Well, there's also the "write a webserver directly into your application" approach. :)

You could also write your application as an Apache module. That gives you a pretty tight coupling into the web server, but it does restrict you to using Apache.

Beyond that, you could build up a framework to maintain and marshal sessions and connections, but at that point you're essentially reinventing FastCGI.

[#] Mon Mar 30 2009 11:43:52 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Heh... I feel like yelling 'first post' or something.

[#] Mon Mar 30 2009 12:17:08 EDT from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Why is fastcgi lame but java servlets not lame? The web server passes the request to the java shit over a socket, just like fastcgi. It's the same exact concept in that respect.

[#] Mon Mar 30 2009 22:44:51 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Beyond that, you could build up a framework to maintain and marshal
sessions and connections, but at that point you're essentially
reinventing FastCGI.

Right and it's kindof amazing that at this point there still isn't a standard solution.
I guess java and .net are the solution.
And if you want fast, you have to roll your own and that's how it is.

[#] Mon Mar 30 2009 22:45:30 EDT from rod @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It's all HTML in the browser no matter what language you code in. Especially if you use lynx browser...

[#] Mon Mar 30 2009 22:46:04 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Why is fastcgi lame but java servlets not lame? The web server passes

the request to the java shit over a socket, just like fastcgi. It's
the same exact concept in that respect.

Concept yet, but (and I'm certainly rusty at my fastcgi) I remember it not being an all encompassing thing, you had to write something depending on what platform you were on.
I forget it was a long time ago, maybe it's not so lame, but it's not as seamless as servlets, which is all I was getting at.

[#] Tue Mar 31 2009 13:14:37 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Right and it's kindof amazing that at this point there still isn't a

standard solution.
I guess java and .net are the solution.

What makes them the solution? They still have to talk to a web server.
The only difference is that someone already integrated it for you. By that standard, PHP "is the solution" and so is Python, Ruby on Rails, etc. etc. etc.

Any web application environment needs to either talk to a web server or act as a web server. It's kind of like a Von Neumann bottleneck of web programming.

[#] Tue Mar 31 2009 23:02:44 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

yes, it's not the talking to the webserver that I'm going on about, it's the integration between the webserver and the application dishing out content, and when you come right down to details, it's how much wasteful shit happens between the GET or POST is accepted and the responding program shits out its first bit of html.
forking a process to run an interpreter to me seems to be a pretty much worse case scenario.
I don't know how ruby does it, but I'm pretty sure it's integrated like java.
php is a good Language for the purpose, but if you run it as a forked process, I don't think you should be doing that in anything but a test program.
Same thing with perl, if you run modperl and whatever the php equivalent must be it's far less worse, but you're still interpreting. I'm guessing modperl persists its compiles? Okay, so less worse even. Then it's just that Ihate perl as a language.
Java for it's bytecode suckyness, at least has everything all compiled and ready to go, and nothing gets forked, and once it starts caching classes, in theory it never even has to go to disk.

[#] Wed Apr 01 2009 00:48:32 EDT from rod @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I can write PHP webpages in vim, ssh'd in from my treo cellphone. I can modify things and fix code if needed. So PHP's has it's pluses, but I do agree that it is not meant for industrial web applications. I'm just getting my feet wet lately with .net so I can't honestly say how that is over all.
I do know that I need IIS, a bloated server OS, all sorts of firewalls and locked down policies to run a asp.net application on a web server; conversely, I can run apache and PHP off a live CD in my toaster oven a serve pages.



[#] Wed Apr 01 2009 07:40:56 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Yea, I don't get the whole microsoft angle.
I have a friend who's a MS weenie, and we got back and forth, he's got every feature and tool and library I do and I've got every feature and tool and library he does.
The difference is, he has to pay up the ying yang for all that software.

The tradeoff: people still pay lots of money for people who do that.
I go where the money is too.
I happen to like unix more than windows, so that's where I go, but really, if I had a problem with tomcat, and he had a problem with IIS we'd be in the same boat.
I *can* find the source and try and fix it, but it's so huge and there's such a learning curve, the reality is that I'm not going to do it, and it might as well be black box.
He can call up support and they Will Fix His Problem.
But again, he has to pay lots of money for that.

[#] Wed Apr 01 2009 17:34:49 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That level of support is available for your environment too if you're willing to pay for it. You have the option of paying or going it alone. He doesn't.

[#] Fri Apr 03 2009 14:58:54 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Hey, does anyone know whether the functionality of "diff" and "patch" are available as a library? Open source only, please...

[#] Fri Apr 03 2009 16:13:45 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I just took a look at the source to gnu diff, and it's got a function called "compare_files"
So it is not in itself a library, but all you have to do is remove the main function and compile, and it is.

[#] Fri Apr 03 2009 16:35:11 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Is it capable of providing a unified diff, suitable for feeding into a patch manager?

[#] Fri Apr 03 2009 16:48:03 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

looks like it:
case 'u':
specify_style (OUTPUT_UNIFIED);

[#] Wed Apr 08 2009 19:36:40 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mo Mär 30 2009 07:56:56 EDT von Ford II <>
Of course it depends on the goal, but my preference for writing a web application is simple java servlets and jsps
The reason is a) eclipse makes development so easy, but really because b) that's what servlets are designed for.
I love C++ more than all the others, but as far as I know fastcgi is still the only way to avoid having to fork a process, and that's still kinda lame.
An application server that can take requests and hand them to already running programs (in the sense that java programs run) and maintain a pool of database connections and other resources, to me, that's the way to go.
Of course I hate the performance hit and the over complexity, but the overall picture is better.

I think php is definetly the best of the lot in terms of cgi making, it was designed to be exactly what it is, and except for the few glaring security flaws, it does its thing well.
I don't know a lot about php, maybe there is a daemon mode it runs in or something.
But it has to be compiled or interpreted no? Nothing like run time interpretation to yield speedy web results.

And my long time fallback: is google written in PHP? I did'nt think so.

The fucked up part, is I think large parts of facebook are.

Java and simple in one sentence? That doesn't mix. Most java guys, questioned "Where's your ear?" will wrap their arm around their head and point to the ear on the opposite side of the arm.



[#] Wed Apr 08 2009 19:39:19 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mo Mär 30 2009 10:57:07 EDT von fleeb <>

Hrm...

Perhaps, for what you're describing, if I wanted extreme performance, I'd use C++, code up a module for apache (presuming the use of an apache server), and have a virtual folder that refers to the module's bits to perform database queries and such.

Setup for such a thing would be fun.

Apache and performance in one sentence? doesn't mix well again.

theres nginx or lighty  or lighthttpd, if it should be fuckin' fast use one of them.

Me started using nginx.



[#] Wed Apr 08 2009 19:59:57 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

ah, and the prefered connection from the webserver-frontend to the backend nowadays _IS_ fastcgi. Ruby or Python frameworks do so. And there also is a better php cgi frontend than the upstream one.

the webserver itself musn't use much memory on many simultaneous connections, so all the calls waiting for gifs and stuff to be read from disk clog up your resources.

NOT tying the application into the webserver frontend has the advantage, that you don't get problems with waiting for your application logic while you should be barfing out files; which would bring in the need to fork/thread the webserver so it could cope applications without blocking file i/o for static content (which for example is one of the last performace problems of webcit). The modern aproaches go with one task, no (or not many) threads and select(). They have real little connection resource overhead (nginx can handle 2000 idle sessions [almos every connection will be idle somewhen in its life cycle] with around one meg of ram usage)

go and figure how to do a thousand simultaneous connections with apache; who uses ~30-50 Megs per child depending on the amount of modules you plug into it...

triple M still has writing a fastcgi frontendmodule into webcit, so nginx integration can be better...



[#] Wed Apr 08 2009 23:08:27 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I stand corrected. fastcgi it is.

[#] Thu Apr 09 2009 12:37:23 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

go and figure how to do a thousand simultaneous connections with apache;
who
uses ~30-50 Megs per child depending on the amount of modules you plug into

it...

isn't that a little unfair? Apache is threaded now. The per-child metric doesn't matter so much anymore.

Go to page: First ... 22 23 24 25 [26] 27 28 29 30 ... Last