Re: Chickens, eggs and stars
Could the system look up the tree from the requested resource for the error script? If no error script is found in the tree it could look for one in a default location. For example, if a request is made for /a/b/c/foo.html Which results in a 404 the system would look in /a/b/c /a/b /a /error For 404.esp WDYT? Paddy Sent via BlackBerry from T-Mobile -Original Message- From: "Bertrand Delacretaz" <[EMAIL PROTECTED]> Date: Thu, 13 Dec 2007 13:58:40 To:sling-dev@incubator.apache.org Subject: Re: Chickens, eggs and stars On Dec 12, 2007 5:52 PM, Michael Marth <[EMAIL PROTECTED]> wrote: > Re issue 1): > > we could have a 404 handler script that kicks in when a non-existing > resource is requested Good idea. Do you have a suggestion about how to select which 404 script to use? Assume I have dropped some scripts under /apps/foo, and I request /content/foo which does not exist. IIUC you'd want in this case to use the /apps/foo/status.404.esp script to handle this error, but how do we decide that this script is more appropriate than, say, /bar/somewhere/404.esp? We might say that we replace the first level of the pathname (/content in this case) with /apps, and use that as a starting point to look for scripts. That's a simple enough rule, but it's a bit constraining. -Bertrand
Re: Chickens, eggs and stars
I did not quite follow the recent discussion about path resolution in case there are multiple apps, but how about this: if you request /content/foo1/foo2 which does not exist microsling walks up the path till it finds an existing resource (say /content/foo1). It would then look for status404.esp at the location where it looks for other scripts that are relevant for /content/foo1 (i.e. depending on the resource type or so). But I think there are 2 open questions with this approach: - what do we do if there is no 404 handler at this location? Walk up the content tree? - how do we specify the mime type of the response? Should the script be named status404.html.esp? On 12/13/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > On Dec 12, 2007 5:52 PM, Michael Marth <[EMAIL PROTECTED]> wrote: > > Re issue 1): > > > > we could have a 404 handler script that kicks in when a non-existing > > resource is requested > > Good idea. Do you have a suggestion about how to select which 404 script > to use? > > Assume I have dropped some scripts under /apps/foo, and I request > /content/foo which does not exist. > > IIUC you'd want in this case to use the /apps/foo/status.404.esp > script to handle this error, but how do we decide that this script is > more appropriate than, say, /bar/somewhere/404.esp? > > We might say that we replace the first level of the pathname (/content > in this case) with /apps, and use that as a starting point to look for > scripts. That's a simple enough rule, but it's a bit constraining. > > -Bertrand > -- Michael Marth, http://dev.day.com
Re: Chickens, eggs and stars
Bertrand Delacretaz wrote: > On Dec 12, 2007 10:52 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > >> Bertrand Delacretaz wrote: >>> ...That's why MicrojaxPostServlet uses a POST to /foo/* to mean "create >>> new child node under /foo", and POST to /foo to mean "update /foo". >>> Using PUT instead would be cleaner of course, but browsers don't do >>> that today. > >> Yes, but you mentioned /foo/*.post.html as the url, which is much more >> ugly than /foo/* > > The POST is done to /foo/*, but David's linotype example uses > /foo/posts/*.post.html as the URL of the page that lists blog posts. > >> ...I think the "post" is superfluous as the method is already post and >> ".html" is not right as content is posted which has nothing to do with >> html > > Yes, that URL is used with a GET, not a POST, and "posts" in there > refers to "blog posts", not the POST method...are we confused enough? > ;-) > > So we're discussing two different things: > > 1) MicrojaxPostServlet uses /foo/* with the POST method, where * means > "create a child node with a generated name under /foo". > > I think we agree that this is ok. > Thanks for the explanation - this all now makes more sense to me. If we prefer /* instead of /, I'm fine as well :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Chickens, eggs and stars
On Dec 12, 2007 10:52 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Bertrand Delacretaz wrote: > > ...That's why MicrojaxPostServlet uses a POST to /foo/* to mean "create > > new child node under /foo", and POST to /foo to mean "update /foo". > > Using PUT instead would be cleaner of course, but browsers don't do > > that today. > Yes, but you mentioned /foo/*.post.html as the url, which is much more > ugly than /foo/* The POST is done to /foo/*, but David's linotype example uses /foo/posts/*.post.html as the URL of the page that lists blog posts. > > ...I think the "post" is superfluous as the method is already post and > ".html" is not right as content is posted which has nothing to do with > html Yes, that URL is used with a GET, not a POST, and "posts" in there refers to "blog posts", not the POST method...are we confused enough? ;-) So we're discussing two different things: 1) MicrojaxPostServlet uses /foo/* with the POST method, where * means "create a child node with a generated name under /foo". I think we agree that this is ok. 2) Davids linotype example uses /foo/*.html with the GET method, to access a SyntheticResource that allows a page to be displayed at a URL where there's no content yet. -Bertrand
Re: Chickens, eggs and stars
On Dec 12, 2007 5:52 PM, Michael Marth <[EMAIL PROTECTED]> wrote: > Re issue 1): > > we could have a 404 handler script that kicks in when a non-existing > resource is requested Good idea. Do you have a suggestion about how to select which 404 script to use? Assume I have dropped some scripts under /apps/foo, and I request /content/foo which does not exist. IIUC you'd want in this case to use the /apps/foo/status.404.esp script to handle this error, but how do we decide that this script is more appropriate than, say, /bar/somewhere/404.esp? We might say that we replace the first level of the pathname (/content in this case) with /apps, and use that as a starting point to look for scripts. That's a simple enough rule, but it's a bit constraining. -Bertrand
Re: use case: resolving a resource based on a node´s version
On Dec 13, 2007 3:13 AM, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > On Dec 12, 2007, at 1:10 PM, Bertrand Delacretaz wrote: > > How about > > > > /content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf > > > > where suffixes starting with s: are reserved for Sling usage? > > yuck. A general principle of web design is that you shouldn't > be able to tell how a server is implemented by looking at the URI,... Right...I had this vague feeling that my example URLs started to look like...no I'm not telling what, but something ugly ;-) > ...What we should do is separate the mapping into a sequence > of extensibility hooks and only define the delegation points. > For example, we know that the path up to the last JCR node > is handled by Sling, so just define everything after that > point (i.e., EXTRA_PATH) as input to a sequence of registered > filters for that resource (where the sequence is itself a > node identified by a property on the resource node, either > explicitly or by default based on node type)... Ok, we can reuse the existing sling:resourceType property, which currently points to a path where processing scripts are found: that path could contain a node that defines this sequence of filters. > ..That would > allow both fine-grained handling of the extra path and > flexibility for legacy resources... Ok - that means having some additional info (besides scripts) in the directory pointed to by sling:resourceType, and nothing prevents this in the current design. IIUC this means we don't need to do anything unless someone needs access to specific versions, as Juanjo suggests: we could then implement a mechanism like you propose, but we already have the "suffix acquisition" and "resource points to a configuration/script area" parts, so we should be fine. -Bertrand
Re: use case: resolving a resource based on a node´s version
> i think that our url processing is complicated enough and i > would really like to delegate everything beyond what we have > now to the application, until we find a usecase that is not > served well by delegating this kind of functionality to the > application. You have convinced me. Definitely, complicating the url processing is a dangerous trend. BR, Juanjo. On Dec 12, 2007 11:14 PM, David Nuescheler <[EMAIL PROTECTED]> wrote: > hi guys, > > i would rather stay away from all that business and just let the > application > handle it. it is important to understand that for versioning jcr does > not have the concept of a head version but the concept of a node > in that particular workspace. so different people can already have > different views on the same content just using different workspaces. > > the cases where someone wants to view or diff special versions > in my can easily be delegated to the application and in my mind > does not need to be a first level concept in sling. > > i would really like to stay away from all the locale since > i find that i would not even like to model that on to the > individual resource in my applications, since i want the tree to > diverge in different locales. > > i think that our url processing is complicated enough and i > would really like to delegate everything beyond what we have > now to the application, until we find a usecase that is not > served well by delegating this kind of functionality to the > application. > > regards, > david > > > On 12/12/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > On Dec 12, 2007 6:27 PM, Juan José Vázquez Delgado > > <[EMAIL PROTECTED]> wrote: > > > > > ...it´s more natural for me to have > > > > > > /content/some/resource.html/version1/lang1 > > > than > > > /content/mytext.a4.print.s:version:1:4.s:locale:fr_CH.html > > > ... > > > > I agree that your suggestion looks nicer (also because you have > > simpler values that might not reflect reality ;-), and that means we > > don't "invade" the selectors space which is good. > > > > I'd still like to define a syntax to differentiate suffixes that are > > handled by Sling/microsling, as opposed to suffixes used by > > applications. > > > > How about > > > > /content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf > > > > where suffixes starting with s: are reserved for Sling usage? > > > > -Bertrand > > >
Re: [continuum] BUILD FAILURE: Sling - Resource Loading and Mapping Management
Felix Meschberger wrote: > Hi, > > Hmm. How do other projects using VMBuild solve this issue ? Good question - for us the problem is that one had to provide the ssh credentials to log into people.apache.org. I'm not sure, perhaps vmbuild has direct file system access to the people site, then we could just copy them instead of sending them through ssh. > > A CI system IMHO is of limited use if the built artifacts are not > deployed after a successfull build (yes, just knowing that builds are > successfull is valuable in itself). True. Carsten > > Regards > Felix > > Am Mittwoch, den 12.12.2007, 18:19 +0100 schrieb Carsten Ziegeler: >> Ok, obviously I was to optimistic with the deployment :( >> The credentials are missing for the deployment, so I will change the >> continuum installation to just "install" our modules; deployment has to >> be done manually. >> >> Carsten >> >> Continuum VMBuild Server wrote: >>> Online report : >>> http://vmbuild.apache.org/continuum/buildResult.action?buildId=28013&projectId=298 >>> >>> >>> Build statistics: >>> State: Failed >>> Previous State: Ok >>> Started at: Wed 12 Dec 2007 09:06:59 -0800 >>> Finished at: Wed 12 Dec 2007 09:12:02 -0800 >>> Total time: 5m 2s >>> Build Trigger: Schedule >>> Build Number: 5 >>> Exit code: 1 >>> Building machine hostname: vmbuild.apache.org >>> Operating system : Linux(unknown) >>> Java Home version : java version "1.6.0" >>> Java(TM) SE Runtime Environment (build 1.6.0-b105) >>> Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) >>> Builder version : >>> Maven version: 2.0.7 >>> Java version: 1.6.0 >>> OS name: "linux" version: "2.6.20-16-server" arch: "i386" >>> >> > > -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [DISCUSS] Community Roles and Processes
On Dec 13, 2007 9:24 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...I posted a proposal for a definition of our Community Roles and > Processes in our Wiki [1]. The central points of this document are the > following:... Thanks - I added some clarifications in there, and reworked some parts for readability, see the page history - there should be no semantic changes. I agree on the proposed role definitions. -Bertrand
Re: [continuum] BUILD FAILURE: Sling - Resource Loading and Mapping Management
Hi, Hmm. How do other projects using VMBuild solve this issue ? A CI system IMHO is of limited use if the built artifacts are not deployed after a successfull build (yes, just knowing that builds are successfull is valuable in itself). Regards Felix Am Mittwoch, den 12.12.2007, 18:19 +0100 schrieb Carsten Ziegeler: > Ok, obviously I was to optimistic with the deployment :( > The credentials are missing for the deployment, so I will change the > continuum installation to just "install" our modules; deployment has to > be done manually. > > Carsten > > Continuum VMBuild Server wrote: > > Online report : > > http://vmbuild.apache.org/continuum/buildResult.action?buildId=28013&projectId=298 > > > > > > Build statistics: > > State: Failed > > Previous State: Ok > > Started at: Wed 12 Dec 2007 09:06:59 -0800 > > Finished at: Wed 12 Dec 2007 09:12:02 -0800 > > Total time: 5m 2s > > Build Trigger: Schedule > > Build Number: 5 > > Exit code: 1 > > Building machine hostname: vmbuild.apache.org > > Operating system : Linux(unknown) > > Java Home version : java version "1.6.0" > > Java(TM) SE Runtime Environment (build 1.6.0-b105) > > Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) > > Builder version : > > Maven version: 2.0.7 > > Java version: 1.6.0 > > OS name: "linux" version: "2.6.20-16-server" arch: "i386" > > > > > > >
[DISCUSS] Community Roles and Processes
Hi all, I posted a proposal for a definition of our Community Roles and Processes in our Wiki [1]. The central points of this document are the following: * Every Committer is also a member of PPMC (Poddling PMC) Some projects choose to clearly separate the roles of Committers and [P]PMC members (e.g. Felix) while other projects do not separate the roles and have each Committer also be a member of the [P]PMC (e.g. Jackrabbit). I have the strong feeling, that people who show interest in a project and participate in the project in way, that they merit committership, should also be trusted such that they shold also be able to participate in [P]PMC level decisions. Of course this raises the barrier to offer committership a little bit, it also much better integrates committers with the project. * Votes on new Committers and PPMC members are held on the PPMC private mailing list In a discussion on the Sling private mailing list, the general consensus seems to be, that votes should be held on the private mailing list as is the case in most Apache projects. Therefore I suggest to codify this consensus. Let's discuss Regards Felix [1] http://cwiki.apache.org/confluence/x/rhsB
