惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 司徒正美
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Last Week in AI
Last Week in AI
大猫的无限游戏
大猫的无限游戏
博客园 - Franky
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
爱范儿
爱范儿
The Cloudflare Blog
阮一峰的网络日志
阮一峰的网络日志
博客园 - 叶小钗
博客园_首页
有赞技术团队
有赞技术团队
WordPress大学
WordPress大学
宝玉的分享
宝玉的分享
V
V2EX
V
Visual Studio Blog
博客园 - 三生石上(FineUI控件)
S
SegmentFault 最新的问题
量子位
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Apple Machine Learning Research
Apple Machine Learning Research
美团技术团队

Secret Weblog

Becoming More Xee: A Modern XPath and XSLT Engine in Rust Looking for new challenges! Repeat Yourself, A Bit The Curious Case of Quentell The Humble For Loop in Rust The Humble For Loop in JavaScript Don Question Best Practices I Was a 1980s Teenage Programmer Part 5: Achieving Assembly I Was a 1980s Teenage Programmer Part 4: The Call of Assembly The Tooling Shift I Was a 1980s Teenage Programmer Part 3: MSX-2 JavaScript: when you need two ways to do it! Empowering Programming Languages Bloat and Retrofuturism Refreshing my Blog Again Random Rust Impressions Apilar: An Alife System I Was a 1980s Teenage Programmer Part 2: Olivetti M24 I Was a 1980s Teenage Programmer: the Alphatronic SolidJS fits my brain Is premature optimization the root of all evil? Framework Patterns: JavaScript edition Roll Your Own Frameworks Framework Patterns Secret Weblog Highlights Refactoring to Multiple Exit Points mstform: a form library for mobx-state-tree Seven Years: A Very Personal History of the Web
Zope community evaluating JSR-170
Martijn Faassen · 2005-07-20 · via Secret Weblog

JSR-170 or the Java Content Repository API, appeared on my radar somewhere early in 2004. JSR-170 is interesting to creators of content management systems because it promises a common API for accessing and manipulating CMS content. Implementing this API in a CMS could bring a number of potential benefits to it, such as interoperability, learnability, not reinventing the wheel, and so on. I go deeper into possible reasons for adopting any specification in my previous article Criteria for evaluating specifications.

JSR-170 has some counts against it. For starters, it's huge. When I first looked at it, its design was also somewhat shaky (and it was even huger), but in the recent versions I did notice large improvements. Finally, from the perspective of the Python world, not the Java world, a Java-based API has some counts against it. Implementing a Java API on top of a Python-based system is not easy if you want the interoperability benefits.

That said, I still think there are possible benefits, so I mentioned it a few times in the Zope world for evaluation. This has been happening recently:

  • Stefane Fermigier has been posting about it on his blog.
  • Tres Seaver has been playing with an implementation on top of Zope 3, and also posted about it. He also mentions the impendence mismatch between Python and Java in the design of APIs.

I think it is an excellent development that members of the community looking outwards like this -- the Zope community has had a tendency to look inward in the past. Even if we choose not to adopt JCR or anything else we look at, at least our choice will have been considered and we will have learned something. This openness is also not unattractive to outsiders looking in at the Zope community.