[...]I don't see how rendering at a higher resoltion is necessary, though...I thought anti-aliasing basically gives you all the benefits of that without the drawbacks. [...]
That is how a supersampling anti-alias filter works. The initial image is generated at a higher resolution (usually power of two) and then filtered to the desired target res.
All this is usually done automagically by the 3D graphics card, but some of the data I'll be viewing won't get rendered directly by the card. I see it as an opportunity to write my own AA filter that cross-samples the stereo images and balances the AA effect between the two views (sometimes allowing a higher frequency signal on one-side and letting the brain interpolate between the eyes). I'm hoping the result will be a sharper overall anti-aliased *stereo* image.
I'm assuming you are referring to a monitor/shutter glasses type system. That's an inaccurate comparison with a head-mounted display. You have to remember that the screen is < 2in. away from your eyes. Most of the entry-level 'pro' stereo head-mounted displays ($5000+) don't get over 1024x768, so $500 for 640x480 really isn't that bad.
I think the motion tracking adds more to the experience than absolute resolution. Your mind can fill in the visual blanks with a little imagination. It can't make up for the lack of basic orientation tracking, parallax effects, and changes in sound with head position. You can add basic head tracking/parallax to a crt/glasses system but the tracking is heavily constrained by the user having to face the monitor. If you want to look skywards you have to adjust your avatar's view with the mouse/keyboard vs just looking up to see above you. This constrained tracking really isn't useful for anything more than simple parallax effects.
My interest in head-mounted displays is for exploring 3d data visualizations and for performing experiments. I can see how 640x480 might be a disappointment for a gamer, but it would work just fine for my uses... Although 640x480 sounds really low it doesn't look that bad. If you render at a higher resolution and scale/filter to 640x480 the results can look quite nice
... However, no affordable, high resolution headsets are available on the market today. (and when I say affordable, I mean for any reasonable price. You cannot get a high resolution head mounted display for even $2000)
Depends on what you consider to be 'high-resolution' for a head mounted display. The Vuzix iWear VR920 boasts dual 640x480 displays and 3DOF head tracking for $400 US. Add a Wiimote to the mix and you can get 6DOF head tracking for $450 + some time getting it all to work together. That's not to shabby when compared to the $2000+ pro-headsets or say a $15,000+ tactical HUD visor:)
[...] Show me a file-oriented data storage method that automatically handles application level semantics.
Any modern relational database has minimal semantics support [...]
I should have been clearer and said 'non-database'... But yes you are correct a formal relational database is great way to store static information it can automatically enforce it's schema and basic semantic integrity. Anyone who uses XML as a replacement for a database is using to much of it. Like I've stressed before XML is a poor format for static data storage. If the data isn't going to be transformed, aggregated, filtered, or translated at some time in the future; then XML may not be best choice for storage. To state it differently: XML is meant to be used for transportation vs. storage of data.
For example, if the message contains a tree data structure that is meant as an update to the data defined as a graph (what is a common application of XML now), standard has to include a definition of all operations that may have to be done when it arrives, including lookup and update, consistency check, etc. The actual implementation that will perform those things in application may be generated from it, and may be extended to perform more data handling [...]
Essentially what you are describing is IDL with a touch of COM. This approach is fine when you have control over your deployment environment and software ecosystem, as is the situation at Google. They [Google] are not advocating Protocol Buffers as a replacement for XML. Anyone who got that impression didn't RTFA. They had a well defined problem and found an effective solution for a process that traditionally might have been done with XML. They are making this technology available in the hopes that others may find it useful in solving their own well defined data transport problems. They are not advocating it as de facto competitor to XML. Protocol Buffers is a framework for creating new binary protocols. To quote the article (emphasis mine):
And now, we're making Protocol Buffers available to the Open Source community. We have seen how effective a solution they can be to certain tasks, and wanted more people to be able to take advantage of and build on this work.
Unfortunately the internet is not well defined and homogenous. The degradation abilities of XML allows disparate clients and processes to interact without having an explicit contract. It means a well designed document can be extended without breaking older clients and processes that were never explicitly designed to talk to each other can.
This a big shift in program design (specifically what constitutes a 'program'). Instead of monolithic code bases you have distributed servlets and transformation processes. A 'program' can be an abstracted service or it could be the description of the processing and filtering chain combining the resources of third party data sources and services.
If you are writing components that only talk to each other and could care less about interoperability or openness(*) then use whatever fits your needs. Nobody is forcing you to use XML (I don't care for evangelism of any kind). But don't poo-poo a technology because it doesn't fit your needs or your style of programming. If your gripe is with people doing stupid things with XML more power to you (but please be clear).
* Yes a published IDL and API libraries are open... One convenient thing about XML is that all you need are a parsing lib and network libs and you can transact with any XML service you don't have to install/compile/maintain a new library for every service (vs. every service having it's own unique protocol). Yes this does mean that XML trends to a lowest common denominator solution, but to allow the creation of laze-fare processes it has to be. Accommodation for the lowest common denominator is whole point of degrad
XML is a system of grammar that is used to create defined formats.
...made for people who slept through compiler courses.
For the record, there is nothing I like more than writing custom parsers its hella fun! That being said; I have things to do other than watch Matlock and write parsers for no good reason (it's like knitting for DPD-11 crowd).
... XML provides ridiculously complex, stupidly designed means to define a syntax, and absolutely nothing to define semantics, so you still have to either document it or, more likely, provide an implementation.
Your argument about implementation is a red herring. If by semantics you are refering to application-level semantics then yes you have to provide an implementation. Show me a file-oriented data storage method that automatically handles application level semantics. You can't because application level semantics are always handled by the implementation. If you write a custom format/parser you can deal with these issues during the parsing phase, but it doesn't remove the fact that this is an implementation level feature.
Guess what? The syntax is such a microscopic part of your task, the amount of work you have just placed into your reference implementation of semantics is multiple orders of magnitude higher than whatever you "saved" by not implementing syntax parser from scratch, leave alone implemented it using any tools that existed long before XML was introduced. The problem is, people who "learn XML" never learn how dead simple parsing in general is, so they use those "frameworks" and "tools" to save what otherwise would be literally seconds of their mental work.
So your suggestion is that I should develop custom file formats and parsers for every single application I write?!?!? That sounds great! I think I'll do everything from now on in custom packed binary! Who needs architecture independence?! Who needs the ability to share or re-use data easily!?! Who needs the ability to read their data outside of the framework it was developed in!?! And what if the specs change? I get to throw out all my existing data and start over again... or get the honor of writting a custom conversion script!!! I'm glad you've made me see the light!
I am not against simplifying further tasks that are already simple if it serves any valid purpose. The problem with XML, it does not really simplify anything, it provides ridiculously amateurish solution for a common easy problem without even a slightest attempt to help with truly complex part of work.
Yes you are right; 1) preparing an ad-hoc representation of my document, 2) automatically generating a schema from it, 3) being able to read/validate instances of the document in 3 line of code is horribly complex!! God forbid the only thing I have to do to get data into/out of my program is check the correctness of the data. God forbid that I don't have to write/debug/maintain a custom parser/format because I'm using one based on standards!
Words "XML", "abstract" and "semantic" do not belong in the same phrase -- XML is developed at the level of a second-year CS student who managed to completely miss what "abstract" and "semantics" mean. It's not "abstract", it's artificial and irrelevant. The only value of XML is the fact that it's some standard, however this does not change the fact that it's nearly the worst possible solution for any imaginable problem.
You fail to understand the big picture and the larger set of interactions the XML family is meant to address W3C Semantic Web Activity.
Have you read anything I wrote? [...]
Unfortunately... I think it's time you had your glass of warm milk and went to bed, you need to be up to greet the mailman at 6am and complain about the adverts that keep showing up in your mailbox.
XML is absolutely definitely a format -- eXtensible Markup Language.
XML is a system of grammar that is used to create defined formats.
You can't use XML to markup data. You have to use a defined grammar to create a format. You might say that this is an issue of semantics but that is the point. If your only use/understanding of XML is as a static data format then your doing it [XML/XSLT/..] wrong.
XML is crappy tool for static storage. If the data is being read/written by the same program there are faster/simpler was to encode that data. But that isn't what XML is meant for. To repeat my previous post; XML documents are abstracted semantic models that are designed to be transformed and dynamically interpreted.
Here is a link to an example of how XML/XSLT can be used to extend and enhance an existing XML based web service [Generating RSS with XSLT and Amazon ECS]. This a perfect example of the agnostic client scenario that XML was designed for (ie: the service could care less how the data is represented or transformed).
That statement underlines most people's myopic vision of the XML family of technologies. XML is not a format it is a family of technologies based around a common grammar.
XML is not a bucket.
It is not a passive container for data.
It is a transformable semantic graph.
The heart and sole of XML is XLST it serves as a common 'glue' that allows the transformation between the various standardized 'languages' XML, XHTML, XLST,
XSL-FO, SVG, RDF, RSS, etc...
Example; the same XML document (lets say it represents rows in a database) can be transformed into a web page, pdf file, visual graph, rss feed, directed graph, or [insert non-XML text based output of choice]. More importantly the transformation can take place on the client side of a transaction effectively decoupling content and representation.
That being said, I completely agree that XML is over-kill for simple fixed message passing. But, then again simple fixed format message passing isn't what XML was really designed for:-) XML was designed for situations where the representation needs of the client are unknown and/or dynamic.
It's about the size of a large SUV, weighing in at 2,400 pounds and measuring 21 feet long and up to 26 feet wide.
I know you Americans have been building large cars but 21x26 feet? Really?
Hell, while I'm at it, there's no such thing as soy milk. it's SOY JUICE! Soybeans don't have and will never have teats. You insensitive clod! I happen to come from a long line of proud soybean milkers! My family has been raising and milking herds of soybeans for several generations. We have come to endure the regular taunts from from our "real" milk neighbors, but this kind of slander on slashdot is just unacceptable! I thinks it is time that people started to educate themselves on the anatomy of soybeans. People really need to take the time to get to know them and their gentle intelligent ways...
Ah, still remember those long summer nights. Sleeping under the stars and driving the beans across the plains...
Serious electrophiles know that knob-and-tube delivers a warmer 'true to life' reproduction of electric power.
IMHO, romex is just way too harsh. It just doesn't have the same ambiance...
But, then again YOU probably couldn't tell!
[/smirk]
Well, seeing as how a friend and I have a client who's being bombarded by NDRs as a result of a joe-job on the client's domain name, it's good to know that DynDNS is copping a clue
Ignoring a problem isn't the same as fixing it... NDRs serve a useful purpose assuming the original message was actually useful.
The problem isn't sending out NDRs. The problem is sending an NDR in response to spam!
I've had to deal with the whole joe-job+NDR+DDOS scenario on several occasions... I have found that 65~80% of this garbage has already been marked as spam by the bouncer! Why in the would would you bounce a message that you _already_ know to be invalid?!?!? All this does is amplify the volume of crap being flung around...
A sanely configured email server should not bounce on spam.
Spam should be left to rot in the bottomless pit of/dev/null.
Remember,
Its not a turd fight if theres only one monkey:-)
Slashdot Mirror
Does this mean that Facebook is claiming "ALL YOUR FACE ARE BELONGING TO US?"
[...]I don't see how rendering at a higher resoltion is necessary, though...I thought anti-aliasing basically gives you all the benefits of that without the drawbacks. [...]
That is how a supersampling anti-alias filter works. The initial image is generated at a higher resolution (usually power of two) and then filtered to the desired target res.
All this is usually done automagically by the 3D graphics card, but some of the data I'll be viewing won't get rendered directly by the card. I see it as an opportunity to write my own AA filter that cross-samples the stereo images and balances the AA effect between the two views (sometimes allowing a higher frequency signal on one-side and letting the brain interpolate between the eyes). I'm hoping the result will be a sharper overall anti-aliased *stereo* image.
Even my crappiest stereo3d rig was 1600x1200.
I'm assuming you are referring to a monitor/shutter glasses type system. That's an inaccurate comparison with a head-mounted display. You have to remember that the screen is < 2in. away from your eyes. Most of the entry-level 'pro' stereo head-mounted displays ($5000+) don't get over 1024x768, so $500 for 640x480 really isn't that bad.
I think the motion tracking adds more to the experience than absolute resolution. Your mind can fill in the visual blanks with a little imagination. It can't make up for the lack of basic orientation tracking, parallax effects, and changes in sound with head position. You can add basic head tracking/parallax to a crt/glasses system but the tracking is heavily constrained by the user having to face the monitor. If you want to look skywards you have to adjust your avatar's view with the mouse/keyboard vs just looking up to see above you. This constrained tracking really isn't useful for anything more than simple parallax effects.
My interest in head-mounted displays is for exploring 3d data visualizations and for performing experiments. I can see how 640x480 might be a disappointment for a gamer, but it would work just fine for my uses... Although 640x480 sounds really low it doesn't look that bad. If you render at a higher resolution and scale/filter to 640x480 the results can look quite nice
... However, no affordable, high resolution headsets are available on the market today. (and when I say affordable, I mean for any reasonable price. You cannot get a high resolution head mounted display for even $2000)
Depends on what you consider to be 'high-resolution' for a head mounted display. The Vuzix iWear VR920 boasts dual 640x480 displays and 3DOF head tracking for $400 US. Add a Wiimote to the mix and you can get 6DOF head tracking for $450 + some time getting it all to work together. That's not to shabby when compared to the $2000+ pro-headsets or say a $15,000+ tactical HUD visor :)
[...] Show me a file-oriented data storage method that automatically handles application level semantics.
Any modern relational database has minimal semantics support [...]
I should have been clearer and said 'non-database'... But yes you are correct a formal relational database is great way to store static information it can automatically enforce it's schema and basic semantic integrity. Anyone who uses XML as a replacement for a database is using to much of it. Like I've stressed before XML is a poor format for static data storage. If the data isn't going to be transformed, aggregated, filtered, or translated at some time in the future; then XML may not be best choice for storage. To state it differently: XML is meant to be used for transportation vs. storage of data.
For example, if the message contains a tree data structure that is meant as an update to the data defined as a graph (what is a common application of XML now), standard has to include a definition of all operations that may have to be done when it arrives, including lookup and update, consistency check, etc. The actual implementation that will perform those things in application may be generated from it, and may be extended to perform more data handling [...]
Essentially what you are describing is IDL with a touch of COM. This approach is fine when you have control over your deployment environment and software ecosystem, as is the situation at Google. They [Google] are not advocating Protocol Buffers as a replacement for XML. Anyone who got that impression didn't RTFA. They had a well defined problem and found an effective solution for a process that traditionally might have been done with XML. They are making this technology available in the hopes that others may find it useful in solving their own well defined data transport problems. They are not advocating it as de facto competitor to XML. Protocol Buffers is a framework for creating new binary protocols. To quote the article (emphasis mine):
And now, we're making Protocol Buffers available to the Open Source community. We have seen how effective a solution they can be to certain tasks , and wanted more people to be able to take advantage of and build on this work.
Unfortunately the internet is not well defined and homogenous. The degradation abilities of XML allows disparate clients and processes to interact without having an explicit contract. It means a well designed document can be extended without breaking older clients and processes that were never explicitly designed to talk to each other can.
This a big shift in program design (specifically what constitutes a 'program'). Instead of monolithic code bases you have distributed servlets and transformation processes. A 'program' can be an abstracted service or it could be the description of the processing and filtering chain combining the resources of third party data sources and services.
If you are writing components that only talk to each other and could care less about interoperability or openness(*) then use whatever fits your needs. Nobody is forcing you to use XML (I don't care for evangelism of any kind). But don't poo-poo a technology because it doesn't fit your needs or your style of programming. If your gripe is with people doing stupid things with XML more power to you (but please be clear).
* Yes a published IDL and API libraries are open... One convenient thing about XML is that all you need are a parsing lib and network libs and you can transact with any XML service you don't have to install/compile/maintain a new library for every service (vs. every service having it's own unique protocol). Yes this does mean that XML trends to a lowest common denominator solution, but to allow the creation of laze-fare processes it has to be. Accommodation for the lowest common denominator is whole point of degrad
XML is a system of grammar that is used to create defined formats.
...made for people who slept through compiler courses.
For the record, there is nothing I like more than writing custom parsers its hella fun! That being said; I have things to do other than watch Matlock and write parsers for no good reason (it's like knitting for DPD-11 crowd).
... XML provides ridiculously complex, stupidly designed means to define a syntax, and absolutely nothing to define semantics, so you still have to either document it or, more likely, provide an implementation.
Your argument about implementation is a red herring. If by semantics you are refering to application-level semantics then yes you have to provide an implementation. Show me a file-oriented data storage method that automatically handles application level semantics. You can't because application level semantics are always handled by the implementation. If you write a custom format/parser you can deal with these issues during the parsing phase, but it doesn't remove the fact that this is an implementation level feature.
Guess what? The syntax is such a microscopic part of your task, the amount of work you have just placed into your reference implementation of semantics is multiple orders of magnitude higher than whatever you "saved" by not implementing syntax parser from scratch, leave alone implemented it using any tools that existed long before XML was introduced. The problem is, people who "learn XML" never learn how dead simple parsing in general is, so they use those "frameworks" and "tools" to save what otherwise would be literally seconds of their mental work.
So your suggestion is that I should develop custom file formats and parsers for every single application I write?!?!? That sounds great! I think I'll do everything from now on in custom packed binary! Who needs architecture independence?! Who needs the ability to share or re-use data easily!?! Who needs the ability to read their data outside of the framework it was developed in!?! And what if the specs change? I get to throw out all my existing data and start over again... or get the honor of writting a custom conversion script!!! I'm glad you've made me see the light!
I am not against simplifying further tasks that are already simple if it serves any valid purpose. The problem with XML, it does not really simplify anything, it provides ridiculously amateurish solution for a common easy problem without even a slightest attempt to help with truly complex part of work.
Yes you are right; 1) preparing an ad-hoc representation of my document, 2) automatically generating a schema from it, 3) being able to read/validate instances of the document in 3 line of code is horribly complex!! God forbid the only thing I have to do to get data into/out of my program is check the correctness of the data. God forbid that I don't have to write/debug/maintain a custom parser/format because I'm using one based on standards!
Words "XML", "abstract" and "semantic" do not belong in the same phrase -- XML is developed at the level of a second-year CS student who managed to completely miss what "abstract" and "semantics" mean. It's not "abstract", it's artificial and irrelevant. The only value of XML is the fact that it's some standard, however this does not change the fact that it's nearly the worst possible solution for any imaginable problem.
You fail to understand the big picture and the larger set of interactions the XML family is meant to address W3C Semantic Web Activity.
Have you read anything I wrote? [...]
Unfortunately... I think it's time you had your glass of warm milk and went to bed, you need to be up to greet the mailman at 6am and complain about the adverts that keep showing up in your mailbox.
XML is absolutely definitely a format -- eXtensible Markup Language.
XML is a system of grammar that is used to create defined formats.
You can't use XML to markup data. You have to use a defined grammar to create a format. You might say that this is an issue of semantics but that is the point. If your only use/understanding of XML is as a static data format then your doing it [XML/XSLT/..] wrong.
XML is crappy tool for static storage. If the data is being read/written by the same program there are faster/simpler was to encode that data. But that isn't what XML is meant for. To repeat my previous post; XML documents are abstracted semantic models that are designed to be transformed and dynamically interpreted.
Here is a link to an example of how XML/XSLT can be used to extend and enhance an existing XML based web service [Generating RSS with XSLT and Amazon ECS]. This a perfect example of the agnostic client scenario that XML was designed for (ie: the service could care less how the data is represented or transformed).
XML is crappy format
That statement underlines most people's myopic vision of the XML family of technologies. XML is not a format it is a family of technologies based around a common grammar.
:-) XML was designed for situations where the representation needs of the client are unknown and/or dynamic.
XML is not a bucket.
It is not a passive container for data.
It is a transformable semantic graph.
The heart and sole of XML is XLST it serves as a common 'glue' that allows the transformation between the various standardized 'languages' XML, XHTML, XLST, XSL-FO, SVG, RDF, RSS, etc...
Example; the same XML document (lets say it represents rows in a database) can be transformed into a web page, pdf file, visual graph, rss feed, directed graph, or [insert non-XML text based output of choice]. More importantly the transformation can take place on the client side of a transaction effectively decoupling content and representation.
That being said, I completely agree that XML is over-kill for simple fixed message passing. But, then again simple fixed format message passing isn't what XML was really designed for
--
If you don't know XSLT you don't know XML
I know you Americans have been building large cars but 21x26 feet? Really?
The FTP links that have been posted DONT COUNT towards the download day stats.
:-)
The official links from download.mozilla.org are:
Win32 (exe):
http://download.mozilla.org/?product=firefox-3.0&os=win&lang=en-US
Linux (tar.bz2):
http://download.mozilla.org/?product=firefox-3.0&os=linux&lang=en-US
OS-X (dmg):
http://download.mozilla.org/?product=firefox-3.0&os=osx&lang=en-US
happy downloading
Ah, still remember those long summer nights. Sleeping under the stars and driving the beans across the plains...
Serious electrophiles know that knob-and-tube delivers a warmer 'true to life' reproduction of electric power.
IMHO, romex is just way too harsh. It just doesn't have the same ambiance...
But, then again YOU probably couldn't tell!
[/smirk]
Ignoring a problem isn't the same as fixing it... NDRs serve a useful purpose assuming the original message was actually useful. The problem isn't sending out NDRs. The problem is sending an NDR in response to spam!
I've had to deal with the whole joe-job+NDR+DDOS scenario on several occasions... I have found that 65~80% of this garbage has already been marked as spam by the bouncer! Why in the would would you bounce a message that you _already_ know to be invalid?!?!? All this does is amplify the volume of crap being flung around...
A sanely configured email server should not bounce on spam. Spam should be left to rot in the bottomless pit of /dev/null.
Remember, Its not a turd fight if theres only one monkey :-)