You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/12/19 17:00:14 UTC
file: prefix, take 2
Jeff, it seems to me that you were pissed off by my veto on your file:
prefix system.
I have tried to explain you what my issues are, and have understood your
vision. I have understood some of your points, and you have seen some of
mine. This shows IMHO that the commit was really too hasty. But the
thread degenerated again, so I want to start anew with it and get to a
solution.
Try to understand that it's very difficult for me to stand behind this
veto, it's not a fun ride. Don't think i made it lightly, nor that it's
a personal thing.
Please give me all the time we need to resolve this thing, because it's
IMHO important for Forrest.
-oOo-
This whole issue is about having the possibility of specifying in the
links that I want to serve a file statically instead of having it served
with transformation from Cocoon.
href="myfile" gives me index transformed by cocoon
href="file:myfile" gives me the file as-is
I have these point in mind, that logically drive me to the conclusion
that the file: scheme is not correct.
1 the source URI space is different from the destination URI space.
2 since Cocoon should be free to transform the files in any way,
thus possibly resulting in different result mimetypes in different
skins/versions, we identify every file only as a filename without
extension, even if the extensions are there.
3 since the path without extension identifies the file, and since
there is only one file with a given id, we can have only one
file with the same name in the same dir.
4 every destination "dir" can thus have only one file with
the same name
Now, given that
5 every file with the same path in the source space should
be available in the same path in the destination space.
Mounted spaces can be attached to the URI space anywhere,
but must keep the dir layout relative to that.
"Same" basically means that they must be in the same dir as
source or as result, even if the dir will change in case of
mounts.
This is because placing them in the same dir has a meaning.
example
./src/documentation/a.xml
./src/documentation/b.xml
./src/documentation/c.xml
./src/documentation/path/d.xml
./src/documentation/path/e.xml
./external/path/to/1.xml
./external/path/to/file/2.xml
(both mounted in resourcemap)
may go to
http://mysite/a.???
http://mysite/b.???
http://mysite/c.???
http://mysite/path/d.???
http://mysite/path/e.???
http://mysite/the/mount-path/path/to/1.???
http://mysite/the/mount-path/path/to/file/2.???
6 every file with the same path+name in the source space should
yield one only file with the same name as a result per content type.
7 every file in the resulting space that has the same name
but different content type must originate from the same source.
Then I conclude that
8 every source"dir" can thus have only one file with the same name
Now, this defeates one of the needs of the file protocol to identify the
file to process, because there is only one file with a given name.
Now, for proper separation of concerns between the editor and the
generation, the editor should not know anything about what Cocoon does
to the file. He just puts a file in a dir and wants it served.
He knows that it will show up in the same path, or in the mounted path,
and that it will have the same name, not necessarily the same extension.
In this scenario, what do we need the file: scheme for?
-oOo-
Practically, we have the problem of having to check which file we should
serve. Why? Because the filesysem insists to encode the mime type in the
name, as an extension.
Cocoon would have to be able to ask for the file with a certain name
without the extension, and then ask for the mimetype.
I said that we needed resource-exists, but actually it's not needed.
We need an Action or similar that given a path, it gets the contents of
that path, gets all the filenames, strips the extensions, maps them to
mime-types, and then Cocoon can select based first on the mime-type of
the source, and then eventually on the XML DTD with CAPs.
In essence, we probably need CAPs for directories instead of files.
I want to see one filename, one dir, one result, one link.
source: /path/filename.any
result: /mount/filename.any2
link: /path/filename
Cocoon would do:
source: /path/filename.any
|
|
V
{name://{1}/{2}} + {mime://{1}/{2}}
then select on mime
then if xml select on DTD
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: file: prefix, take 2
Posted by Jeff Turner <je...@apache.org>.
On Fri, Dec 20, 2002 at 08:35:51AM +0100, Nicola Ken Barozzi wrote:
>
> Jeff Turner wrote:
> [...]
> >What I said about -1s is a
> >completely generic belief I have formed after watching Avalon tear itself
> >apart. If my little rant about -1s were posted to avalon-dev in response
> >to a PD/SC flamefest, I think you'd agree with it.
>
> I do not think our discussion was a flamefest. I'm sad you took it as
> such, because I honestly took all my time to find a solution.
>
> >I think you'll find if you _express_ your opinions without _forcing_ them
> >via a -1, you'll get a much less defensive reaction. I will personally
> >revert anything you want to -0.9 until I've understood your point.
>
> Then tell me, what is the reason why reverting it with a -1 feels much
> worse than with a -0.9?
-0.9 gives the committer the benefit of the doubt, while still expressing
the voter's strong feelings. Why should they be given the benefit of the
doubt? Because, although everyone has an opinion, they _did_ something
about it, and practical experience means their opinion is statistically
more likely to be correct.
Remember, Forrest is very young, in design phase. Who cares if we make a
wrong technical choice? No doubt the wrong choice will become apparent
in time, and then we'll fix it. One wrong step does not doom the
project.
In the current case, my patch solved a major problem in Forrest. Who
cares if it was the "right" solution? Code can be fixed. As long as it
keeps Forrest users happy, it builds the community, which is what
matters.
> A -0.9 means: you can keep it in, but I don't like it.
That is -0.
> A -1 means: I really think it's a problem. Revert it because there are
> some issues I feel are very important, and I will discuss them to death
> to find a solution.
And users are left without _any_ solution to a real problem, while
committers try to attain 100% agreement on abstract concepts they dreamt
up while typing (me anyway:), and may be completely irrelevant in the
long run. Is this the way for Forrest to progress and gain users?
> Negative -1s are ones that block things without trying to find a
> solution. I am really trying hard, and if you feel it's a waste of time,
> think about *my* time too.
Yes, it wasn't really fair compare your -1 to an Avalon -1, and lots of
constructive discussion did emerge. It didn't take a -1 ("You are wrong
until you convince me otherwise") to bring it about though.
> I respect your opinions enough to reply to you each single time with a
> discussion trying to explain points *and* give a solution to the
> controversy.
>
> As anyone, I may be wrong, my -1 could be completely off target, but
> given the points that came through and the amount of ideas, I'm more
> than confident that in fact my veto has reason to be, because it
> demonstrates that the discussion on this important point in Forrest
> wasn't through.
It will never be through, and 100% consensus is not required for
progress. There may be some beautiful theoretical model of how Forrest
should work, but I don't know it and I'm not waiting on us to discover it
before doing anything practical.
> I don't play with vetos, and if once I did a mistake, I immediately
> rectified it. If you stiull feel I'm doing it, then there is no way I
> can tell you it's not the case. I'm not able to explain myself better
> than this, sorry.
I hope this email convinces you that you are not duty-bound to veto
everything that you don't like. Just SAY "that sucks", and explain why,
and all the benefits of a -1 will result, without the negatives.
> >For
> >example, if I'd forced through the original patch I'd have never
> >encountered that excellent bit of thinking about inverting sitemaps for
> >CLI optimizations.
>
> I gather that it would not have happened if I didn't force you to
> discuss with a -1.
I don't know why you think that.
> Don't think that forcing code in CVS makes people think. Discussions
> do.
Here's a relevant .sig:
-----------------------------------------------------
First, we shape our tools, thereafter, they shape us.
-----------------------------------------------------
and another:
- verba volant, scripta manent -
> I'm not going away, but again, I'm too disillusioned to find the force
> to discuss. I prefer to discuss these things on the Cocoon list, where
> we know why Cocoon works this way and what the meanings are, and where
> in fact we have already found a possible solution to the CLI speed.
Cocoon works same as here.
> >>Thank you all, but this is just too much.
>
> I'm sorry, but after all the pushing I've been through these days, I
> just can't take anymore.
That's why we have holidays.
--Jeff
Re: file: prefix, take 2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
[...]
> What I said about -1s is a
> completely generic belief I have formed after watching Avalon tear itself
> apart. If my little rant about -1s were posted to avalon-dev in response
> to a PD/SC flamefest, I think you'd agree with it.
I do not think our discussion was a flamefest. I'm sad you took it as
such, because I honestly took all my time to find a solution.
> I think you'll find if you _express_ your opinions without _forcing_ them
> via a -1, you'll get a much less defensive reaction. I will personally
> revert anything you want to -0.9 until I've understood your point.
Then tell me, what is the reason why reverting it with a -1 feels much
worse than with a -0.9?
A -0.9 means: you can keep it in, but I don't like it.
A -1 means: I really think it's a problem. Revert it because there are
some issues I feel are very important, and I will discuss them to death
to find a solution.
Negative -1s are ones that block things without trying to find a
solution. I am really trying hard, and if you feel it's a waste of time,
think about *my* time too.
I respect your opinions enough to reply to you each single time with a
discussion trying to explain points *and* give a solution to the
controversy.
As anyone, I may be wrong, my -1 could be completely off target, but
given the points that came through and the amount of ideas, I'm more
than confident that in fact my veto has reason to be, because it
demonstrates that the discussion on this important point in Forrest
wasn't through.
I don't play with vetos, and if once I did a mistake, I immediately
rectified it. If you stiull feel I'm doing it, then there is no way I
can tell you it's not the case. I'm not able to explain myself better
than this, sorry.
> For
> example, if I'd forced through the original patch I'd have never
> encountered that excellent bit of thinking about inverting sitemaps for
> CLI optimizations.
I gather that it would not have happened if I didn't force you to
discuss with a -1. Don't think that forcing code in CVS makes people
think. Discussions do.
I'm not going away, but again, I'm too disillusioned to find the force
to discuss. I prefer to discuss these things on the Cocoon list, where
we know why Cocoon works this way and what the meanings are, and where
in fact we have already found a possible solution to the CLI speed.
>>Thank you all, but this is just too much.
I'm sorry, but after all the pushing I've been through these days, I
just can't take anymore.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: file: prefix, take 2
Posted by Jeff Turner <je...@apache.org>.
On Thu, Dec 19, 2002 at 06:55:42PM +0100, Nicola Ken Barozzi wrote:
>
> Jeff Turner wrote:
> >On Thu, Dec 19, 2002 at 05:00:14PM +0100, Nicola Ken Barozzi wrote
>
> [...]
> >I'll defer replying to the rest of this email till a more civilized hour.
>
> No need to, I revert any -1.
Thanks
> Please do as you wish, I'm not going to work seriously on Forrest
> anymore now, if I ever will. I'm going in bugfix mode, and you won't
> hear me in discussions anymore.
>
> I feel I have been deeply offended by your mail.
Sorry, that was not the intention :( What I said about -1s is a
completely generic belief I have formed after watching Avalon tear itself
apart. If my little rant about -1s were posted to avalon-dev in response
to a PD/SC flamefest, I think you'd agree with it.
I think you'll find if you _express_ your opinions without _forcing_ them
via a -1, you'll get a much less defensive reaction. I will personally
revert anything you want to -0.9 until I've understood your point. For
example, if I'd forced through the original patch I'd have never
encountered that excellent bit of thinking about inverting sitemaps for
CLI optimizations.
--Jeff
> Thank you all, but this is just too much.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
Re: file: prefix, take 2
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
> > Nicola Ken Barozzi wrote
>
> [...]
> > I'll defer replying to the rest of this email till a more
> > civilized hour.
>
> No need to, I revert any -1.
>
> Please do as you wish, I'm not going to work seriously on Forrest
> anymore now, if I ever will. I'm going in bugfix mode, and you won't
> hear me in discussions anymore.
>
> I feel I have been deeply offended by your mail.
>
> Thank you all, but this is just too much.
Come on guys, lighten up. We cannot do without either
Jeff or Ken. Both of you have worked wonders to get
the project this far.
Sorry that i cannot help out with the technical issues
- i can only read, because it is way over my head. Though
i do see the importance. Please keep on.
--David
Re: file: prefix, take 2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Thu, Dec 19, 2002 at 05:00:14PM +0100, Nicola Ken Barozzi wrote
[...]
> I'll defer replying to the rest of this email till a more civilized hour.
No need to, I revert any -1.
Please do as you wish, I'm not going to work seriously on Forrest
anymore now, if I ever will. I'm going in bugfix mode, and you won't
hear me in discussions anymore.
I feel I have been deeply offended by your mail.
Thank you all, but this is just too much.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: file: prefix, take 2
Posted by Jeff Turner <je...@apache.org>.
On Thu, Dec 19, 2002 at 05:00:14PM +0100, Nicola Ken Barozzi wrote:
>
> Jeff, it seems to me that you were pissed off by my veto on your file:
> prefix system.
Very observant. I take email composition seriously. This one took an
hour to write. Add up the hours, and this has been a significant waste
of life.
> I have tried to explain you what my issues are, and have understood your
> vision. I have understood some of your points, and you have seen some of
> mine. This shows IMHO that the commit was really too hasty. But the
> thread degenerated again, so I want to start anew with it and get to a
> solution.
>
> Try to understand that it's very difficult for me to stand behind this
> veto, it's not a fun ride. Don't think i made it lightly, nor that it's
> a personal thing.
> Please give me all the time we need to resolve this thing, because it's
> IMHO important for Forrest.
Yay, a disagreement before we even get to the little -oOo-
We agree on the important part, which is that copying static files and
Javadocs should be done as a CLI optimization. I'm sure that given
another week's emailing :) I'm sure I could convince you that an Ant copy
is an acceptable hack in the meanwhile.
But all this opposition to whether static links have a 'file:' prefix is
_really_ absurd.
-1 means, "This is an IMPORTANT issue in which I'm SURE I'm right, and am
willing to risk wasting everyone's time and generate lots of negativity
to defend that view".
-1 is NOT synonymous with "I disapprove".
Now, is whether we have a 'file:' prefix important? If it turns out to
be unnecessary, we tell people to stop doing it, write a 10 line XSLT to
strip the 'file:' for backwards-compat, and by Forrest 0.4 no-one will
have remembered it. This is *early* in Forrest's development cycle, and
mistakes are allowed.
Then, Are you absolutely positively *sure* you're right? Can you picture
a world where 95% of URLs start with site:, java:, person:, mail: etc,
and say with complete confidence, "a file: prefix is out of place"?
If I were running Apache, there would be a rule: more than 5 -1s per 6
months and you get dragged before the PMC to explain your actions,
because something is wrong, possibly with the project, but probably with
the committer. -1s are community destroyers. From observation here and
on avalon-dev, I think you treat them far too much like candy.
I'll defer replying to the rest of this email till a more civilized hour.
--Jeff