Am I reading the wrong article in the NYT? I can't find any reference to "artificial selection" or "that the current lull in our physical evolution is by 'choice'" in the article, as stated below by the original poster. The NYT article states that the causes of the speedup in evolution are 1) a larger population to select from, 2) disease. What am I missing? I keep looking through the NYT article to find the connection but I just don't see it.
Slur writes "The New York Times reports an insightful theory of Human evolution that gives credit for our accelerated evolution to the evolving brain. By virtue of our aesthetic and utilitarian preferences we ourselves have been responsible for molding the present human form and consciousness. Applied to other species we call it 'artificial selection,' but the new theory implies we did it all quite naturally, unconsciously, and that the exponential evolutionary acceleration we have achieved as a species in recent time is just what you'd expect. It also suggests that the current lull in our physical evolution is by 'choice' as well."
From your reply I'm not sure whether you're asking about a single record or the entire database.
Each record is loaded into cache separately, and records are evicted when the cache is full according to an LRU algorithm. The total size of a database can therefore exceed the size of main memory and swap.
But for a single record, in most cases it is completely loaded into cache, even when a partial get/put is performed. Even when using memory mapping with the BDB C Edition, in most cases the complete record is loaded. This is why we say that there is no special support for BLOBs in BDB.
If you have further questions, please post to the BDB newsgroup for questions on the C Edition, or the bdbje mailing list for questions on the Java Edition, or to support@sleepycat.com for either product. I'm afraid I will miss your reply if we continue to discuss this here. Here are links for posting questions:
Hello, this is Mark Hayes, I'm one of the BDB Java Edition developers.
There are no restrictions on accessing partial records in BDB Java Edition -- it is the same as the BDB C Edition in this respect. However, you may have a misunderstanding about the way partial records work in both products: neither product has a BLOB capability.
In both products, when you do a partial get/put of a record, the entire record must be loaded into the BDB cache. The only advantage of a partial get/put is that it reduces the amount of memory copied between the BDB cache and your buffer. If you need the performance of a true BLOB implementation for very large records, I'm afraid you won't get it by using either BDB product.
We do get requests for a true BLOB capability from time to time. We have not implemented it yet, because it will take significant effort to implement it in a way that performs well for very large records. And the number of requests have not yet been high enough to outweigh other requested features.
Please keep the requests for this capability coming in if you need it. We do factor in these requests when we do product planning.
XML really doesn't change any of the domains EXCEPT the presentation domain.
I only partially agree. In the presentation domain, XML can be used to isolate the logical structure of the data from the HTML/WML/etc. It's very useful for this, but beware of the slowness of XSLT (as others have commented). I found that using the fastest XSLT (the jclark version) it still took around 300 ms to produce about 20K of HTML from XML.
In my situation, much of the XML was static information, so I decided to generate JSP output using XSLT instead, since JSP is compiled; the same could be done with another compiled scripting lanuguage. What was most interesting to me was the problem of isolating the static parts of the page, which could be compiled in JSP, from the dynamic parts, which had to come from the database / application layer. In this case, the tag extensions in the latest JSP (1.1) are very handy. They allows the JSP file to be a well-formed XML document, and therefore easily generated by XSLT, and the extended tags can be programmed to interact with the application layer in a very clean way. The tag extensions could be programmed to either interact with an application object, or a XML DOM, although actually the latter is more cumbersome.
I agree that XML is not very valuable as a direct interface to the database -- there should always be a layer between the database server to enforce access control, implement rules, etc. However, XML is useful as an exchange format between loosely connected servers, such as in B2B interactions. In these cases it is better than using distributed objects, because the coupling is looser and easier to define. But I'm of the opinion that the XML should represent a high-level operation, not database rows.
My biggest gripes about frames are: 1- The keyboard interface for using up/down arrows to scroll requires that the frame being scrolled has the keyboard focus. This means you have to move/click over the scrolling frame before you can use the keys to scroll, which is tantamount to making the arrow keys useless. As a user preferring keyboard to mouse, I would much rather have the whole page scroll than have to use the mouse. 2- As a developer, I know creating content for frames is more costly. In addition to dealing with one "page" split over multiple HTTP requests, there is the issue that frames can't resize dynamically to fit their content, meaning that layout using pixel sizes is many times necessary, which in turns causes all kinds of compatibility problems. Last but not least there is the problem that browsers just don't support frames consistently, and I almost always have to write browser-specific code to get them to work properly. Worst of all is trying to support a frames or no-frames preference.
If what Dave Winer writes is true then SOAP sounds like one of the engineering-driven projects at MS as opposed to a marketing-driven project. After reading this I became fairly positive about the whole thing and I think the experimentation with XML protocols will be good overall.
Slashdot Mirror
I posted a reply.
Mark
From your reply I'm not sure whether you're asking about a single record or the entire database.
l
Each record is loaded into cache separately, and records are evicted when the cache is full according to an LRU algorithm. The total size of a database can therefore exceed the size of main memory and swap.
But for a single record, in most cases it is completely loaded into cache, even when a partial get/put is performed. Even when using memory mapping with the BDB C Edition, in most cases the complete record is loaded. This is why we say that there is no special support for BLOBs in BDB.
If you have further questions, please post to the BDB newsgroup for questions on the C Edition, or the bdbje mailing list for questions on the Java Edition, or to support@sleepycat.com for either product. I'm afraid I will miss your reply if we continue to discuss this here. Here are links for posting questions:
http://dev.sleepycat.com/community/discussion.htm
Mark
Hello, this is Mark Hayes, I'm one of the BDB Java Edition developers.
There are no restrictions on accessing partial records in BDB Java Edition -- it is the same as the BDB C Edition in this respect. However, you may have a misunderstanding about the way partial records work in both products: neither product has a BLOB capability.
In both products, when you do a partial get/put of a record, the entire record must be loaded into the BDB cache. The only advantage of a partial get/put is that it reduces the amount of memory copied between the BDB cache and your buffer. If you need the performance of a true BLOB implementation for very large records, I'm afraid you won't get it by using either BDB product.
We do get requests for a true BLOB capability from time to time. We have not implemented it yet, because it will take significant effort to implement it in a way that performs well for very large records. And the number of requests have not yet been high enough to outweigh other requested features.
Please keep the requests for this capability coming in if you need it. We do factor in these requests when we do product planning.
Thanks,
Mark
I only partially agree. In the presentation domain, XML can be used to isolate the logical structure of the data from the HTML/WML/etc. It's very useful for this, but beware of the slowness of XSLT (as others have commented). I found that using the fastest XSLT (the jclark version) it still took around 300 ms to produce about 20K of HTML from XML.
In my situation, much of the XML was static information, so I decided to generate JSP output using XSLT instead, since JSP is compiled; the same could be done with another compiled scripting lanuguage. What was most interesting to me was the problem of isolating the static parts of the page, which could be compiled in JSP, from the dynamic parts, which had to come from the database / application layer. In this case, the tag extensions in the latest JSP (1.1) are very handy. They allows the JSP file to be a well-formed XML document, and therefore easily generated by XSLT, and the extended tags can be programmed to interact with the application layer in a very clean way. The tag extensions could be programmed to either interact with an application object, or a XML DOM, although actually the latter is more cumbersome.
I agree that XML is not very valuable as a direct interface to the database -- there should always be a layer between the database server to enforce access control, implement rules, etc. However, XML is useful as an exchange format between loosely connected servers, such as in B2B interactions. In these cases it is better than using distributed objects, because the coupling is looser and easier to define. But I'm of the opinion that the XML should represent a high-level operation, not database rows.
My biggest gripes about frames are: 1- The keyboard interface for using up/down arrows to scroll requires that the frame being scrolled has the keyboard focus. This means you have to move/click over the scrolling frame before you can use the keys to scroll, which is tantamount to making the arrow keys useless. As a user preferring keyboard to mouse, I would much rather have the whole page scroll than have to use the mouse. 2- As a developer, I know creating content for frames is more costly. In addition to dealing with one "page" split over multiple HTTP requests, there is the issue that frames can't resize dynamically to fit their content, meaning that layout using pixel sizes is many times necessary, which in turns causes all kinds of compatibility problems. Last but not least there is the problem that browsers just don't support frames consistently, and I almost always have to write browser-specific code to get them to work properly. Worst of all is trying to support a frames or no-frames preference.
If what Dave Winer writes is true then SOAP sounds like one of the engineering-driven projects at MS as opposed to a marketing-driven project. After reading this I became fairly positive about the whole thing and I think the experimentation with XML protocols will be good overall.