nolan

The problem with the speed test is that you're trying to benchmark your own bandwidth (which is more lilely than not variable based upon load) against the variable bandwidth of another server whose capacity you aren't even fully aware of. So basically you're benchmarking between two fluctuating mile markers. That might be okay if you're just looking for a quick, no-consequence estimate, but doesn't serve much of a professional purpose.

They don't have to be explicitly declared in the document to be created (that is, the elements can be created through Javascript). Additionally, Javascript includes share a namespace, meaning that include A gets to use the methods of include B and so forth. You can look through the bulletin boards include files if you want to see how anything related to it is created. The source for the main Gmail interface (since you mentioned it before) can be accessed via https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=http://mail.google.com/mail/&scc=1&ltmpl=googlemail&emr=1. You didn't mention any of my other points. As a general note to thread viewers, you can see what the W3C HTML 5 draft has to say about iframes (not deprecated) here: http://w3c.github.io/html/

[1] Quatrux: Do yourself a favor and take a look at the script powering the shoutbox: http://forums.xisto.com/jscripts/shoutbox/shoutbox.js. While you're at it, bring up a 'Find' dialog box and type in iframe. If you'd like, you can do the same thing for the Gmail source. Case in point: What you said is inaccurate, and could have been verified in a couple of seconds if you wanted to double-check for yourself, rather than simply trying to shoot what I said down ineffectively and without any prompt to do so. [2] As another correction so that future viewers don't get misled: you -cannot- always use CSS to accomplish the same things you can accomplish with iframes. For example, you cannot create an upload form using css that doesn't redirect away from the current page without relying on Flash/Java/etc if you don't want to use frames/objects. You can use AJAX+CSS to accomplish some of the things an iframe can, but not all of them (efficiently, at least), although that also relies on the viewer having Javascript enabled. For your other point, it is true that iframe contents are not indexed by search engines, although this is only if another direct link is not provided to the same url elsewhere on the site. This usually doesn't matter due to the fact that it's very rare that you want the content indexed (e.g., if the iframe is a chat box, an upload form, or a data aggregator). If you do want it to be indexed, chances are high that it can act as a stand-alone webpage and should be linked to directly elsewhere. Also, for your point about text browsers, alternative solutions (when includes aren't an option) work just as badly or worse. Try loading up an AJAX-intensive website in a text browser and see what happens. [3] Using iframes is -not- a bad practice unless they are used for the wrong reasons. As I've mentioned, you -cannot- always achieve the same results through other methods. When using them, you -should- consider accessibility issues and you -should- consider better alternatives, -if- possible, although that is not always the case.

BuffaloHelp is correct. A couple of other things worth noting are that an e-mail interface is not an inherent part of an SMS gateway (with the exception of SMSC gateways). I cannot think of a single example where an e-mail interface has not been provided, however, whether because of its inclusion within the mainstream software powering SMS gateways or due simply to convention. In the case of an e-mailed message, the SMS gateway is functioning essentially the same, with the sole difference that its interpretation of the input is adjusted to parse the appropriate information from a mail message (again, with a couple of exceptions). The output remains unchanged. On another note, there are middleware providers of SMS solutions. These are still SMS gateways, but they allow you to utilize their gateway to add SMS/MMS functionality to your programs via APIs. I can't think of any that are completely free, though. (Well, I can recall one, but its daily limits were incredibly low. I can try to snoop out the address if you'd like.)

To begin, I'm a designer, so that naturally affects the way that I look at things. That being said, I consider at least half of the websites I come across to be ugly. I consider them so for a number of reasons, but the typical reasons are: the design was cluttered, the arrangement/navigation made little sense, the site required excessive viewer interaction to find what they need, there were too many animations, there were excessively bold or otherwise poor color choices, or there was a lack of consideration for accessibility.STILL, however, I have to acknowledge the old saying that "beauty is in the eye of the beholder". What looks good to me won't necessarily look that great to you, and vice-versa. Chances are that the person who designed the website you mentioned thought it wasn't that ugly, or else they probably wouldn't have made it look the way they did. (That or they simply didn't care.)

I'm going to have to second this. For many languages (and compared to other free translation services), Google translate performs exceptionally well. There was a time a few years back when I used Babel fish's free translation services and I can remember typing a sentence in, translating it to another language, and then translating the result back to the original language and seeing something with a completely different meaning. With Google I (personally) have not encountered this problem to any considerable degree.

Personally, I enjoy the mountains theme. I'm often inclined to use natural themes. Some of the more abstract themes just make my eyes hurt after looking at them for too long.Prior to using the mountains theme (before it was available) I used an oriental theme of some sort that depicted a cartoon fox and his garden. I liked it because it wasn't overly bold and the colors meshed well with each other.In the end, I can live with just about any theme where the colors compliment each other and the elements aren't obsessively bold.

Hello. To begin, I've made more than enough posts to become hosted. I'm not interested in having another hosting account (I pay for my hosting), but we'll disregard that as a logical fallacy. When it comes to correcting inaccuracies that could mislead others, yes, I feel a drive to do so. As for contributing "lesser informed views", my view is accurate and testable. You, on the other hand, have contributed absolutely nothing of consequence in your post. True "fledglings" are those who do not yet have their own ideas to contribute. Moving along, you eluded to me being corrected. Please demonstrate what precisely that correction is (for the benefit of thread viewers) and provide evidence supporting the "correction". (That's what should be done when arguing a point, after all.) Finally, as to you believing your level of technical knowledge exceeds my own, that's highly debatable, although I truly couldn't care less. I did not claim to know more than you or anyone; I merely made an (accurate) correction to a statement that could dissuade new developers from making use of a technology that is perfectly valid to use and widely adopted by established organizations. I've also provided a list of organizations to back up that statement. I hope that helps to clarify any constructs that might have initially evaded your grasp.

This is incorrect. Scientists do not know (beyond hypotheses) the placement of black holes. It is true, however, that objects in space are in constant motion. Additionally, in many scientific communities it is believed that black holes reside at the center of many galaxies, but there is no evidence that our world is growing either closer or farther away from the physical center of our galaxy. To get back on point for the original question, it's not far-fetched to believe they exist. If you're looking for scientific proof, there are many even more practical theories that are as yet still theories and not law. In the end, time will tell, but I'd say it's a safe bet.

Hi, You mentioned my name below but I'm not sure that this is a response to what I said, as it seems more like a general statement. I don't disagree that PHP is the most widely available language in terms of web host availability. I hesitate to say "most popular" for any language due to the fact that "popular" is relational to perspective. If you're referring to popularity by volume of use by all web developers, yes, I'd say PHP is the most popular. If you're referring to popularity amongst professional developers only, the picture might change. If you're referring to popularity by actual web app usage, again, it would be an entirely different story. That's not considering popularity amongst specific development communities/niches, either. As for the point about performance, again I don't disagree, although this is compensated for through scalability. The thing you then have to consider is how much money you want to soak into hardware resources to maintain an app in one language versus another (that is, would you rather have 6 computers scaling a Language X app or 3 scaling a Language Y app, all else equal). Once more, though, everything is relative. Someone might know, for example, that Lift outperforms Django and Ruby on Rails in terms of web framework speed, but does that mean they'll necessarily choose the faster framework? No. And in this case, for good reason (the Lift documentation is horrible). The ease-of-use, general functionality, and other aspects of a language also play a vital role in driving these decisions. It all goes back to the point I'd mentioned in my post: all languages have their own advantages/disadvantages.

Hi again, Iframes are used all over the place for advanced and semi-advanced web apps. At the top of my head, Gmail and Google Wave both use iframes, not to mention this bulletin board (the shoutbox is an iframe). In some places, Yahoo uses iframes, Bing uses them in image results (I believe Google does, too). Amazon and eBay use iframes... The list goes on and on. In short, you do know of a lot of places out there that use iframes, sometimes it's just not apparent/significant that they do

Your network connection (or another part of your network) would have to be horribly misconfigured for it to reduce your potential bandwidth by half. In reality, this isn't likely to be the case. Even default configurations are reasonably well-suited to provide high throughput/overall throughput. And if it were true that a substantial population of users were suffering from a 50% speed reduction, Internet providers would either receive a lot more complaints about falsely advertised bandwidth ratings or would have to essentially double the throughput speed they advertise to offset the loss due to typical configurations.Small to moderate increases, on the other hand (say, of the 1-20% variety), could be possible through minor tweaking, although you would want to make sure you understand the settings you are adjusting before modifying them (e.g., they could be set lower than their maximum value intentionally to assist with error checking, etc.).

if (you_want_to_learn_php) { try { /* reading the manual */ } } The documentation for just about any language is a really good place to start trying to learn the language. You can find the PHP manual here: http://php.net/manual/en/. It includes a quick getting started tutorial, as well. The Tizag tutorials are also nice. They're available at tizag.com.

PHP is a very useful language. It's highly available (probably the most readily available of interpreted languages offered by web hosts), easy to learn, has a nice lineup of language methods, is scalable, has intuitive (built-in) database access methods, and (in my opinion, anyway), is incredibly easy to learn.On the down side, the PHP namespace is somewhat cluttered, although most people who try to attack the language exaggerate this issue, due to the fact that many of the method names aren't names you'd naturally come up with, unless they're there to serve the same purpose. Additionally, PHP is not entirely object oriented (types are not objects), unlike with other languages such as Ruby. (Being able to do things like array.each { code } is much more efficient than creating a for or while loop to iterate through an array.)Most popular languages are good languages to develop with, as well as a few unpopular ones. Each language has its own advantages and disadvantages. Don't bother following hype because it changes all the time, and no matter what language you end up using, there'll be people dead set on trying to explain to you how awful your language choice was. Just ignore them. People don't make amazing web apps (or any other kind of app) by arguing about which language is better and for what reason. Review a little bit, find a language that suits you, use it, and get things done.

I'm not sure you read my post thoroughly. iframes are a type of framing (hence "inline frames", their name). Too many people disassociate iframes and frames from one another, when in fact they rely on many of the same underlying functions of a browser and are both considered members of the frame family. iframes are still very much in use, and are in fact used more frequently today than in the past. In addition, and as I mentioned, iframes are not deprecated in the HTML 5 spec as they are for XHTML, so they're going to be perfectly valid for the future.