In one Ignite Chicago panel, Day’s own scientists and experts gathered to address any possible question about Day, JCR, CQ5, CRX and open development coming from the audience starving for answers. Here’s the scoop.
The panelists participating in the Q&A session included:
- Roy Fielding, Chief Scientist
- Greg Klebus, Sr. Product Manager
- Lars Trieloff, Product Manager
- Jean-Michel Pittet, SVP oF Engineering
- Gerd Hanke, Director of Product Management
Q: Is it possible to do group matching from an AD group to the same group in CQ? I cannot find this in documentation.
A: The functionality is there, we’ll look into making sure documentation is clear on this.
Q: What is the future of Day’s involvement in open development and open standards under Adobe?
A: We will keep doing what we are doing right now, addressed the question Roy Fielding. We will continue using OSGi and open development and design, continuing to be on the leading edge of server-side OSGi.
Day will continue being a part of the Apache Software Foundation (ASF). Adobe is, actually, looking to learn from Day in this field, we just need to figure out how to do that. Adobe is a big company, but we’re a good match and just need to figure out how to improve both companies.
Regarding the future of open standards outside of Day, what I tell people is that I am lousy at making predictions, but good at making everyone do what I want them to do. Right now, I am working on Waka – a protocol for HTTP replacement. I just need to publish it before the acquisition closes in 2 weeks [laughs].
HTML5 is a big huha in standards. It’s a great open standard. The problem though is that it is a browser development standard, and not even browsers agree with what’s in it. Calling HTML5 a standard right now is a joke, really. It will take a year or two for that to shake out.
Q: How do you get involved in open development?
Fielding answered with his personal story on how he got into the open standards field. He was paid to do research and had freedom to write about web technology. As a result, he wrote about something that became a worldwide standard [HTTP].
Other panelists added their suggestions and recommended communicating on ASF mailing lists as one of the ways to get involved. Within W3C, it is a little more complicated to get involved, but possible. Another way is if you have an idea, find an existing project or standard and ask the participants and committers of that project directly on how to get involved. Maybe there’s an extension waiting to materialize.
Q: Are there any plans to move from jsp to jsf?
A: CQ5 was built to support flexibility in the choice of frameworks. Even though the product ships mainly in jsp, it also includes examples of other technologies. The goal is to give customers the most flexibility if they have already made investments into existing infrastructures. JSF has a lot more session-oriented interactions, and Day usually tries to steer away from session-centric development and go towards RESTful interactions vs. the heavy session-based interaction.
Q: Do we keep legacy, Spring MVC work or replace it with Day?
Fielding again chimed in with a tongue-in-cheek comment: Replace everything, but I say that because I don’t have production responsibilities.
The deal is with a lot of migrations and different layers of architecture is to turn to the REST paradigm – you can wrap all apps with new apps and use them as a data source. JCR has same principles.
But still, this is never an easy process. Different ways exist as to how to use CQ5: either to manage content directly from it, or can use one of your own apps to retrieve content from CQ instead.
It becomes a business trade-off: how well can you solve your business issues with one or the other technology and what are the benefits (Do you want drag-and-drop?
Q: What are some of the biggest challenges of Day’s dev team?
A: We used to have a marketing challenge (explaining to the market what we had built). But we are lucky that Eric [Hansen] and Kevin [Cochrane] have joined the team. Plus, a combination of things in the industry, an opportunity to be in the right place at the right time when we came out with CQ5. That was a 10-year effort.
CQ4 had a repository, but not the app. In CQ5, you can see the great architecture.
Q: Why do you manage images in CQ in a DAM folder and pages outside of that folder?
A: By design, there are different locations for storing pages and assets. Users are used to having definite locations for storing, structuring and organizing sites, pages, languages. And all assets (and their renditions) go into their own structure. It is more about findability and content management.
Q: What do you think about the future of RDF and semantic web?
A: Nothing to do with technology, but semantic web is based on idea of wrapping all logic with RDF metadata to start using global web as a knowledge base. The problem here is around how people use the web, how they make links, the actual semantic uses of the web. RDF says only one meaning for a URI, but the same picture of a beach can be interpreted from many semantical perspectives.
Web is a messy place. RDF and semantic web is two-fold: web society on one side and mathematicians on the other side. These two views of the world are not compatible. Eventually, they [the latter] will get tired of trying to change the world.
Q: What is the future of CRX persistence? Will the new persistence technologies like CouchDB, Cassandra, etc. used in the persistence layer?
A: [Submitted by Greg Klebus] The Apache Jackrabbit team (Jackrabbit provides the core repository implementation in CRX) has been working on the new repository architecture for the next major release (Jackrabbit 3). The final architecture hasn't been decided yet, and the community still keeps the options open as to which persistence technologies to support in the persistence layer. The RDBMS databases (supported now) as well as these new persistence technologies (CouchDB, Cassandra, etc) are considered.
Day developers -- being the major contributors to Apache Jackrabbit -- have been leading this discussion.
Secondly, Day CRX has its own scalable file-system-based TarPM persistence technology. From the CRX & CQ5 product perspective this will be an additional persistence option on top of those supported by Apache Jackrabbit.
From the architectural standpoint the most important questions to be asked before settling down on a specific set of persistence models for CRX 3 (and Jackrabbit 3) are:
- From the architecture standpoint: What are the goals of the new persistence model? What characteristics are we focusing on and what tradeoffs will we accept
- From the product standpoint: What are the needs persistence/deployment needs of the majority of applications running on CRX?
Everyone interested in shaping the future of JCR persistence in CRX, CQ5 and Jackrabbit is invited to follow discussions on the Apache Jackrabbit mailing lists, and to contribute ideas and feedback.