On 31 Aug, 2008, at 01:57 , oldmoe wrote:
> If they see shortcomings in the current ones, why don't they just > contribute their fixes > so every one benefits? The main reason behind this is that we want a generalized API, much like JDBC or ADO.net do for Java and .NET. This generalized API can also be used for other types of adapters, such as CouchDB and for example a REST API. The current ruby-pg gem does support async indeed, but for example Rails doesn't use it. It requires a completely different way of programming, because the asynchronous handling is not abstracted away, but directly exposed to the programmer. Using it in a framework like Activerecord or Datamapper would not be trivial, it would require a bunch of additional logic, but it would be doable. But then again, I'd rather use something like Fibers, but since 1.9 is not a viable main stream target atm, just like implementations like Rubinius, so actually being able to use it in production environments is not just around the corner. This not withstanding, I'd love to see a fiber implementation. It would be a good thing to try out and forward compatibility to 1.9 is also nice to actually test. I know that Rubinius is also going to adopt fibers (it already has a Task mechanism which can do something similar), but for implementations likes JRuby it's a lot harder, because the JVM doesn't provide the underlying necessities afaik. -- Regards, Dirkjan Bussink --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
