Re: microsling: extension vs. mime-type script resolution
Hi, On Nov 19, 2007 11:10 PM, Roy T. Fielding [EMAIL PROTECTED] wrote: On Nov 19, 2007, at 11:57 AM, Jukka Zitting wrote: Though, on a tangent, I'm wondering if we could achieve the same use cases with just the existing URL-to-JCR-path mapping. [...] The disadvantage is that it makes a mess of hierarchical access control and relative links. Very bad. We could also do something like .../path/to/document/pdf (or even ../path/to/document?format=pdf though that's a bit ugly and requires special case code) to make relative links easier. Access controls shouldn't be a concern as long as they're embedded within the underlying repository. My main concern is that we are currently splitting the URIs four ways (resource path, selectors, extension, suffix) when I think we could do just as well with two parts (resource path, suffix). This would IMHO make the URI mapping much more straightforward and flexible, at the price of moving part of the mapping code from the Sling framework itself to the servlet components deployed in Sling. BR, Jukka Zitting
Re: microsling: extension vs. mime-type script resolution
Hi, On Nov 20, 2007 1:53 AM, Padraic I. Hannon [EMAIL PROTECTED] wrote: I guess I am a bit confused as to what is wrong with /path/to/document.pdf /path/to/document.html I'm most concerned about two things, one minor and the other more fundamental. The minor issue is that . is a valid JCR name character, so using it as a separator is IMHO a bit counterintuitive. Though I must admit that Sling handles this pretty well and the resulting URIs often look quite natural (like something served from a filesystem). The more fundamental issue is that IMHO Sling hardcodes way too much of the URI mapping process. The whole process is quite complicated and filled with string parsing and constructing, repository traversal, etc. I'm left wondering if we really do need all this. I believe we could achieve all the same functionality and a lot more flexibility with a cleaner URI mapping approach. BR, Jukka Zitting
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Hi, On Nov 18, 2007 4:45 PM, David Nuescheler [EMAIL PROTECTED] wrote: I think a .getNode() would be much less confusing and more direct. If someone should ever need a getItem() or even a .getRawData() i think we could always address that later. +1 I would even go as far as questioning the need for the Resource interface in the first place; why not use Node instead? PS. I may well be too much of a reductionist with this and the URI mapping issue. Perhaps I should start writing nanosling. Just kidding... ;-) BR, Jukka Zitting
Re: Sling and microsling scenarios
Hi, Am Montag, den 19.11.2007, 11:01 +0100 schrieb Thomas Mueller: x Sling applications using only 1 JCR Repository Probably the main question is, are there any fixed paths? This is basically supported. And yes, there are some fixed paths (at least in microsling, but also in Sling). But the question is not actually 1 JCR Repository but 1 workspace in the same JCR Repository. Because as long as the Sling instances use different workspaces, it does not matter, whether the workspaces are located in the same repository or not. If you mean sharing a workspace between multiple Sling instances: This is also quite possible. In fact, this is required if we want to run Sling in a clustered environment, where we will have multiple instances of Sling accessing the same clustered JCR Repository. Of course the Sling Application running inside Sling has to be carefull as to respect the situation that there may be fellow Sling Applications. Regards Felix
Re: Sling and microsling scenarios
Hi, Am Montag, den 19.11.2007, 10:47 +0100 schrieb Juanjo Vázquez: Accordingly, I´m wondering if Sling is intended to support all the next situations: 1 Sling distribution = 1 application + 1 JCR Repository This is probably the default, right ? So I assume this must be supported. 1 Sling distribution = n applications + 1 JCR Repository 1 Sling distribution = n applications + n JCR Repositories I am not sure, what you mean by application. I understand a Sling Application to be a bunch of OSGi bundles deployed to a single Sling instance. So if the bundles are well behaved (whatever that means, but it sounds cool) and for example respect each other's repository space there should be no problem of installing multiple Sling Applications in the same Sling instance. Now, for these applications using multiple repositories: This is more daunting as a single Sling instance is generally set up with a specific workspace (the default workspace) which the SlingAuthenticator logs in to. If a certain Sling Application uses another repository, it has to setup the connection and authentication itself (yes, the respective repository bundles may be of help here, of course). This raises the question: Running multiple Sling instances in the same VM: This is quite possible by for example having a servlet container and deploying multiple Sling instances as multiple web applications. Each Sling instance can be configured to use a separate repository (or each may use the same). For instance, I´m not sure if Sling or microsling should enable to get a RMI deployed repository. Yes, for Sling the jcr/jackrabbit-client project allows accessing a non-embedded repositories using JNDI or RMI. microsling only allows accessing a repository available in the same VM in the default Jackrabbit way. Regards Felix
