When I sat down to write this post I decided to glance back at my last post on this blog. One sentence in particular jumped out at me: "...I would never again feel compelled to build an [Object-Relational] Mapping framework in Java." Well, friends, never say never. Now that we've unveiled an early look at Java support for Google App Engine, I'm thrilled to announce the availability of a JDO and JPA implementation for the App Engine datastore under the Apache 2 open source license.
The App Engine datastore is an incredible piece of technology. Based on Google's own Bigtable, it's one of the key reasons App Engine enables developers to write web applications that scale without infrastructure headaches. But, it isn't necessarily what most of us are accustomed to using for persistence. Wouldn't it be lovely if we could use an existing programming model on top of the datastore API? And wouldn't it be even lovelier if that existing programming model simplified the process of porting web applications on and off App Engine?
Fortunately for us Java developers we have not one, but two persistence standards at our disposal, JDO and JPA. And, to make adopting these persistence standards easier, we have the DataNucleus project (formerly JPOX), which provides plugins that connect these standards to various types of datasources. Andy Jefferson, founder of the DataNucleus project, was not only enthusiastic about our effort to add an App Engine plugin to his project, he was also incredibly helpful (thanks Andy!). I hope you're as excited about the results as I am: Standards-based persistence for the App Engine datastore!
Since App Engine for Python launched almost a year ago I've admired not just the applications that have been built by the developer community but the infrastructure as well. Even though the DataNucleus App Engine plugin was developed by Googlers, it uses the public App Engine APIs that are available to everyone. It uses no backdoors or special privileges. Rather, it is merely the first instance of what I hope will be a torrent of Java infrastructure developed for App Engine for Java. Feel free to peruse the code at http://code.google.com/p/datanucleus-appengine. If you find a bug, send us a patch. And if you think you can do better, do better! There's absolutely nothing stopping you.
Showing posts with label standards. Show all posts
Showing posts with label standards. Show all posts
Tuesday, April 7, 2009
Wednesday, May 14, 2008
Introducing Google Doctype
The open web is the web built on open standards: HTML, JavaScript, CSS, and more. The open web is a beautiful soup of barely compatible clients and servers. It comprises billions of pages, millions of users, and thousands of browser-based applications. You can access the open web with open source and proprietary browsers, on open source and proprietary operating systems, on open source and proprietary hardware.
Google has built its business here, on the open web, and we want to help you build here too. To that end, we are happy to announce the formation of an encyclopedia for web developers, by web developers: Google Doctype.
In its current (beta) form, Google Doctype contains dozens of articles written by top Googlers on topics important to all web developers: security, performance, caching, DOM manipulation, CSS styling, and more. It contains over 8,000 lines of JavaScript code: Google's own battle-tested JavaScript library, released today under a liberal open source license. And it contains the beginnings of a test-driven reference of the open web: a reference of every element, every attribute, every DOM method, every CSS property, all backed up by test cases.
Well, not quite every property; at least, not yet. We're still working on filling in a few of the details about the world's largest development platform ever, and we need your help. And so we humbly offer this fledgling encyclopedia under a Creative Commons Attribution license, and we invite the web developers of the world to contribute to it. Sign in with your Google account and edit any page, any article, anywhere. Create new ones, update old ones, and help expand the world's understanding of the open web.
Friday, February 15, 2008
IETF Applications Area Architecture Workshop
On February 11 and 12 Google hosted the Internet Engineering Task Force (IETF) Application Area Architecture Workshop. This was a chance for people active in the IETF Applications Area to get together and work on architectural issues, topics that span many specific groups in the Applications area.
The Applications Area is the part of the IETF that deals with applications
"...that is, things that are not security (part of the security area), nor networks (most of the other areas), but rather things that use the networks and security services to provide things of benefit to the end-user."This was of particular interest to me since that includes specifications like the Atom Syndication Format and the Atom Publishing Protocol, which we use extensively at Google. From the call for participation:
"These should be a few pages of text on some topic related to Applications area architectural issues. Since the group of attendees is expected to span HTTP and AtomPub, email, IM, calendaring, directories and more, issues should be of interest to more than one of these groups. Some existing Applications architecture "modules" that already are reused include SASL, URLs, MIME types, XML and XML schemas and namespaces, HTTP as a substrate, TLS, ABNF, BEEP."We had around 20 attendees and the breakout sessions ranged over all the topics listed above and many more. There were two days of great conversation and everyone had a good time.
"Thank you for the high quality hosting and convenience of location and food!"-Lisa Dusseault (Apps Area Director)
Friday, September 14, 2007
Google welcomes ISO decision on OOXML
Google welcomes the ISO decision to not approve the fast track of Office Open XML (OOXML) proposed standard DIS 29500 (ECMA 376).
Our engineers conducted an independent analysis of the OOXML specification and found several areas of concern, which we communicated both to the ISO and to the public. These include and are not limited to the following:
The ISO approval required at least 2/3 (i.e., 66.66%) of the votes cast by participating (P) members to be positive, and no more than 1/4 (i.e., 25%) of the total number of national body votes cast negative. Neither of these criteria were met by the proposed standard.
The concerns from many technical experts around the world were submitted as comments by the voting bodies to ISO on September 2, 2007. These must now be resolved at a Ballot Resolution Meeting (BRM) on February 25-29, 2008. In contrast, ODF was approved unanimously (23-0 among P members, 31-0 overall) as an international standard by ISO in May 2006.
As we represented our position in many countries, we were encouraged by the process observed in some places that truly evaluated the proposed standard on its technical merits as well as the feasibility of implementing the standard for the people of the country. These countries successfully declined or abstained due to insufficient information about the standard or the lack of time to evaluate the specification. In addition, many irregularities have been reported in the voting process (see here, here and here).
Technical standards should be arrived at transparently, openly, and based on technical merit. Google is committed to helping the standards community remain true to this ideal and maintain their independence from any commercial pressure.
Google supports one open document format and calls on industry participants to collaboratively work on ODF. With multiple implementations of one open standard for documents, users, businesses and governments around the world can have both choice and freedom to access their own documents, share with others and pass onto future generations.
Our engineers conducted an independent analysis of the OOXML specification and found several areas of concern, which we communicated both to the ISO and to the public. These include and are not limited to the following:
- for a specification of this size it was not given enough time for review;
- the undocumented features of OOXML prevents its implementation by other vendors;
- dependencies on other Microsoft proprietary formats and their technical defects makes it difficult to fully implement; and
- the overall cost for vendors of implementing multiple standards (hence the lack of OOXML implementations in the marketplace).
The ISO approval required at least 2/3 (i.e., 66.66%) of the votes cast by participating (P) members to be positive, and no more than 1/4 (i.e., 25%) of the total number of national body votes cast negative. Neither of these criteria were met by the proposed standard.
The concerns from many technical experts around the world were submitted as comments by the voting bodies to ISO on September 2, 2007. These must now be resolved at a Ballot Resolution Meeting (BRM) on February 25-29, 2008. In contrast, ODF was approved unanimously (23-0 among P members, 31-0 overall) as an international standard by ISO in May 2006.
As we represented our position in many countries, we were encouraged by the process observed in some places that truly evaluated the proposed standard on its technical merits as well as the feasibility of implementing the standard for the people of the country. These countries successfully declined or abstained due to insufficient information about the standard or the lack of time to evaluate the specification. In addition, many irregularities have been reported in the voting process (see here, here and here).
Technical standards should be arrived at transparently, openly, and based on technical merit. Google is committed to helping the standards community remain true to this ideal and maintain their independence from any commercial pressure.
Google supports one open document format and calls on industry participants to collaboratively work on ODF. With multiple implementations of one open standard for documents, users, businesses and governments around the world can have both choice and freedom to access their own documents, share with others and pass onto future generations.
Subscribe to:
Comments (Atom)