Re: [RT] Improving Sitemap and Flowscript

[Nicola Ken Barozzi]

Finally :-)

Stefano Mazzocchi wrote, On 16/08/2003 0.11:

 Virtual Pipeline Components
 ---
...
It has been identified in several circumstances (but mostly dealing with 
blocks) that the need to use pipeline fragments is required.
+1

Had been thinking the same thing for some weeks now for Forrest usage 
especially after the realization of the "bug" that makes resources 
misbehave (I'm so used to writing them the "right" way that I never 
found it).

   - o -

 Moving Sitemap components into cocoon.xconf
 ---
-0

Don't have the need. Would like it more if each sitemap can have it's 
own cocoon.xconf besides it.

 Pluggable Request Factories
 ---
Cocoon needs a simple way to deal with complex HTTP usages, such as 
binary uploading, XML-RPC, WebDAV or SOAP.
+1

After a lot of discussion with Sylvain and input from many other people, 
I propose the introduction of a new sitemap element named 
"map:adaptRequest" that works by adapting the Request object into a more 
specific object that will parse the request and provide API-level access 
to the request.
Stupid suggestion here, but what about map:adapt-request that is more 
xml-ish?

...
 1) uploading granularity
 2) mailet request handling (that can be made a special request factory 
and evolve independently from our environment)
Finally ;-)
   - o -
  Interception in Flowscript
 
I like the concept, and as I see you touting it here, I humbly ask you 
to take a look and give a brief comment about pipeline-level AOP I had 
suggested in my RT:

[Aspect-based pipelines and link view]
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105689706128203&w=2
As for javascript AOP, read this:

[AOP Fun with JavaScript]
http://freeroller.net/comments/deep?anchor=aop_fun_with_javascript
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: [RT] Improving Sitemap and Flowscript

[Gianugo Rabellino]

Stefano Mazzocchi wrote:

You might need to have access to the response too. In WebDAV world, as 
an example, you need to set a whole bunch of headers (Allow:, DAV:, 
MS-Author-Via - yuck - and more), and a DASL component needs to 
specify the search vocabularies supported. True, you can do it by 
hand, but it would be much better if such manipulation could be done 
by a "request-factory".
Damn, great point.

So, back one step: could "adapt-environment" help? or is "environment" 
not good enough for people to understand?

What do others think?
For the record, I'm +1 for it.

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)

Re: [RT] Improving Sitemap and Flowscript

[Gianugo Rabellino]

Boon Hian Tek wrote:

[and it seems that nobody is catching up with my plan for 
implementation so I will have to get my hands dirty and implement the 
whole thing by myself, :-(
Can't speak for others but I think the plan is still too complex for
most of us to follow at this point.
Oh, and I did read the rest of your mail, and you were right about 
AAA, interceptors and flow. I understand now. Thanks for your 
repeated efforts in educating the clueless. ;-D


What is AAA? I tried looking throught the mailing list but was too
lazy to scour through tons of AAA. None of the recent mail I can find
gives an explanation of AAA. Is it something related to AOP?
Authentication, Authorization and Accounting, the three phase that make 
up an application security. Authentication is "who you are", 
authorization is "what you can do", accounting is "what you have done".

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)

Re: [RT] Improving Sitemap and Flowscript

[Boon Hian Tek]

Stefano Mazzocchi wrote:
[and it seems that nobody is catching up with my plan for implementation 
so I will have to get my hands dirty and implement the whole thing by 
myself, :-(
Can't speak for others but I think the plan is still too complex for
most of us to follow at this point.
Oh, and I did read the rest of your mail, and you were right about 
AAA, interceptors and flow. I understand now. Thanks for your repeated 
efforts in educating the clueless. ;-D
What is AAA? I tried looking throught the mailing list but was too
lazy to scour through tons of AAA. None of the recent mail I can find
gives an explanation of AAA. Is it something related to AOP?

For this reason, I'm prepared to stand against years of people's inertia 
on radical paradigm changes, so I wouldn't say "clueless", I would just 
say "inertial".

But I have seen too many faces "illuminated" by the continuations 
:)

concepts. I can only wonder what continuations and interception, 
together, can do to them ;-)
--
Boon Tek

Re: [RT] Improving Sitemap and Flowscript

[Stefano Mazzocchi]

On Sunday, Aug 24, 2003, at 17:58 Europe/Rome, Steven Noels wrote:

Stefano Mazzocchi wrote:

One day I hope the anti-flow/pro-action people will simply stop 
sneaking doubts and come up with real arguments on why we shouldn't 
heavily bet on the flow.
I thought we were done with this balkanization thing, didn't we? I for 
one have just finished my first tiny flow-based application, and while 
I still find the edge layer where Java & Javascript meet each other 
quite murky, I had good fun while hacking on it. It's not about just 
black & white, Stefano.
The edges are rough. I cannot agree more. But this is *exactly* why I'm 
working hard in designing ways to polishing those edges without making 
anything else rougher.

Anyway, criticizing keeps use flow-lovers honest and with feet on the 
ground, so keep it up.


What I would like to see, even if some of it might be nonsense, is a 
seriously integrated scripting environment to code the behaviour of a 
webapp, and flowscript is a nice way to start exploring that concept. 
With serious, I mean there should be a way to work with persistency, 
security, and back-end business logic without this stupid Packages 
thing, and, because of the continuous bouncing back & forward between 
Java and JS, not having to worry about the automagic typecasting that 
happens on the border between Java & Javascript.
I hate the "Packages" syntax as much as you do, believe me. But with 
real blocks, you will do

 var component = cocoon.getComponent(..);

after having deployed your block live and you'll automagically get what 
you want (with implicit versioning and all that).

It will be the *real* dream of avalon finally coming true, versioned 
hotdeploying of components cannot be given by no technology out there 
(only .NET has such a concept, but they don't have continuations!)

Syntax-wise, I have about the same problem with JS as I have with 
Java, but that's because I find Python a tad more readible. There's 
people around here that would rather like to code flow in real Java, 
with dynamic recompilation and all that. There's room for diversity, 
and we should exploit that. Even Apples hooks in with the flow at some 
point. And Apples doesn't mean anything more to me than a 
personal adventure of a guy I like, on the same level of appreciation 
that Dywel has in my mind: nothing wrong with it, but where's the 
community?
What does the above have to do with adding interception to the flow?

We should work on serious JS-wrapping of services typically used in 
webapps, and extensive Avalonization of existing Cocoon code can help 
with that. There should be formalization of the border area between 
Java & JS, or we will kill ourselves with recurring user questions 
about the lack of explicit semantics & casting.
I totally agree, but again, this cannot work without blocks.

[and it seems that nobody is catching up with my plan for 
implementation so I will have to get my hands dirty and implement the 
whole thing by myself, :-(

Over time, I still hope that some Jython guru will pop up and make all 
this also possible using a language I've come to appreciate above JS, 
but that's entirely IMHO.
once you have a way to add continuations in java, you can have your 
jython thing for free.



Of course, if we start from a discours of "either you're with us, or 
you're against us", well, all this might take a long time to happen. 
As much as you repeatedly come back on this so-called split between 
pro and contra, I'm quite sure that you are currently misguiding 
yourself (and through such remarks, also this community) about this 
so-called polarization. For myself, I started hating overweight 
sitemaps a long time ago. I'm also pretty sure some of the old 
action-farts will be amongst the people who, eventually, will make 
sure flowscript reaches the same level of robustness, documentation 
and user support that the 'old stuff' already has.
As I said, costructive criticism helps to keep people honest and I 
appreciate that.

I just happen to be a little nervous when I hear comments that don't 
look costructive. And yes, I might be too sensible on the issue, given 
the past discussions.

Oh, and I did read the rest of your mail, and you were right about 
AAA, interceptors and flow. I understand now. Thanks for your repeated 
efforts in educating the clueless. ;-D
When we add interception to a flowscript with continuations, we'll be 
so much ahead of the current state of the art that people will need a 
time machine to understand what we are talking about.

For this reason, I'm prepared to stand against years of people's 
inertia on radical paradigm changes, so I wouldn't say "clueless", I 
would just say "inertial".

But I have seen too many faces "illuminated" by the continuations 
concepts. I can only wonder what continuations and interception, 
together, can do to them ;-)

--
Stefano.

cvs commit: cocoon-2.1/src/blocks/linotype/samples/stylesheets news2rss-2.0.xslt

[stefano]

stefano 2003/08/24 10:52:03

  Modified:src/blocks/linotype/samples/stylesheets news2rss-2.0.xslt
  Log:
  fixed validation problems with RSS2 and allowed escaped markup in  
which is rendered correctly by news aggregators such as NetNewsWire. The images link 
are still broken though, will fix this when it bugs me enough.
  
  Revision  ChangesPath
  1.3   +18 -6 
cocoon-2.1/src/blocks/linotype/samples/stylesheets/news2rss-2.0.xslt
  
  Index: news2rss-2.0.xslt
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/linotype/samples/stylesheets/news2rss-2.0.xslt,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- news2rss-2.0.xslt 26 Jun 2003 03:09:49 -  1.2
  +++ news2rss-2.0.xslt 24 Aug 2003 17:52:03 -  1.3
  @@ -4,6 +4,7 @@
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; 
xmlns:n="http://www.betaversion.org/linotype/news/1.0";
xmlns:h="http://www.w3.org/1999/xhtml";
  + xmlns:dc="http://purl.org/dc/elements/1.1/";
   >
 
 
  @@ -11,12 +12,12 @@
 
 
  
  - 
  +
Stefano's Linotype
http://www.betaversion.org/~stefano/linotype/
Stefano Mazzocchi's weblog
  - en
  - Copyright 2003 Stefano Mazzocchi. Some rights reserved.
  + Stefano Mazzocchi
  + Copyright 2003 Stefano Mazzocchi. Some rights reserved.

Linotype 1.1

  @@ -27,11 +28,22 @@
 
  
   
  - //
  - 
  -
  +//
  +
  +
  +
  
 
  +
  + 
  +<>
  +
  +
  + 
  +
  + =""
  +
  + 
   
 
  
  
  
  

[BUG] Expired Continuations are not cleaned up?

[Carsten Ziegeler]

Hi,

it seems that the CommandManager of the Excalibur Event package
is not working as expected. If you add a command to the sink
of the CommandManager it's never executed.
Unfortunately, this code is used in the ContinuationsManager
for testing against expired continuations. But the
execute() method of ContinuationInterrupt is never invoked!

So, it seems that there is a bug somewhere in the event package
and our manager is not working properly.

Why is the CommandManager instantiated in Cocoon.java, put
into the Context and get out of it in contextualize in the
ContinuationManagerImpl? The CommandManager is only used
there. IMHO it would be much cleaner to either move the
initialization to the ContinuationManagerImpl or to make
a real component out of it. Passing components in the context
seems to be a hack, no?

I think, a simple solution would be to switch to the cornerstone
scheduler component. This component works (see the scheduler sample
in the scratchpad) and removing the CommandManager usage should also 
fix the shut-down problems with Tomcat entered as a bug that annoyes 
many users.
But if someone is able to fix both problems in the event
package I'm fine with that as well of course.


Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/

Re: [RT] Improving Sitemap and Flowscript

[Steven Noels]

Stefano Mazzocchi wrote:

One day I hope the anti-flow/pro-action people will simply stop sneaking 
doubts and come up with real arguments on why we shouldn't heavily bet 
on the flow.
I thought we were done with this balkanization thing, didn't we? I for 
one have just finished my first tiny flow-based application, and while I 
still find the edge layer where Java & Javascript meet each other quite 
murky, I had good fun while hacking on it. It's not about just black & 
white, Stefano.


What I would like to see, even if some of it might be nonsense, is a 
seriously integrated scripting environment to code the behaviour of a 
webapp, and flowscript is a nice way to start exploring that concept. 
With serious, I mean there should be a way to work with persistency, 
security, and back-end business logic without this stupid Packages 
thing, and, because of the continuous bouncing back & forward between 
Java and JS, not having to worry about the automagic typecasting that 
happens on the border between Java & Javascript.

Syntax-wise, I have about the same problem with JS as I have with Java, 
but that's because I find Python a tad more readible. There's people 
around here that would rather like to code flow in real Java, with 
dynamic recompilation and all that. There's room for diversity, and we 
should exploit that. Even Apples hooks in with the flow at some point. 
And Apples doesn't mean anything more to me than a personal 
adventure of a guy I like, on the same level of appreciation that Dywel 
has in my mind: nothing wrong with it, but where's the community?

We should work on serious JS-wrapping of services typically used in 
webapps, and extensive Avalonization of existing Cocoon code can help 
with that. There should be formalization of the border area between Java 
& JS, or we will kill ourselves with recurring user questions about the 
lack of explicit semantics & casting.

Over time, I still hope that some Jython guru will pop up and make all 
this also possible using a language I've come to appreciate above JS, 
but that's entirely IMHO.


Of course, if we start from a discours of "either you're with us, or 
you're against us", well, all this might take a long time to happen. As 
much as you repeatedly come back on this so-called split between pro and 
contra, I'm quite sure that you are currently misguiding yourself (and 
through such remarks, also this community) about this so-called 
polarization. For myself, I started hating overweight sitemaps a long 
time ago. I'm also pretty sure some of the old action-farts will be 
amongst the people who, eventually, will make sure flowscript reaches 
the same level of robustness, documentation and user support that the 
'old stuff' already has.

Oh, and I did read the rest of your mail, and you were right about AAA, 
interceptors and flow. I understand now. Thanks for your repeated 
efforts in educating the clueless. ;-D

Cheers,


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

[ot] pipeline based programming languages?

[Stefano Mazzocchi]

I was looking around today and found this:

  http://www.cag.lcs.mit.edu/streamit/papers/streamit-lang-spec.pdf

The day the cocoon sitemap become a StreamIT clone with an XML syntax, 
I sware, I'm out of here.

--
Stefano.

Re: [RT] Improving Sitemap and Flowscript

[Stefano Mazzocchi]

On Sunday, Aug 24, 2003, at 08:35 Europe/Rome, Steven Noels wrote:

Stefano Mazzocchi wrote:

If you talk to os kernel folks, they think authentication should 
happen right at TCP/IP stack level, if you talk to httpd, they will 
give you an apache module, if you talk to servlet engine folks, they 
will give you a web.xml descriptor or, if you are lucky, a servlet 
filter, if you talk to sitemap lovers, they will give you an action.
Out-of-the-blue-thought (and I had way too much wine last night): 
shouldn't this 'action-in-sitemap' thing be alleviated by an 
'orthogonal-to-the-matchers' thing in the sitemap? So that you end up 
with a section in the sitemap describing the content-generating 
artefacts, and another one listing the authentication realms, maybe 
using the same matcher-like constructs describing which portions of 
the URI space should be protected?
What you are describing is separating the "content-producing artefacts" 
from "navigational behavior describing semantics".

It's just another way of saying "pipeline" and "flow", respectively.

If you follow that paradigm, you will, pretty soon, understand that the 
semantics you need to fully describe flow will hardly be easy to write 
inside the sitemap, then you will end up rewriting what we already have.

I'm having the slight feeling we are moving stuff into flowscript that 
can mess up good URI practices.
I'm trying hard but I don't see it: rather the opposite. By providing 
layers of interception, we would be providing a "transparent" way to 
add AAA around any URL without worrying about making the AAA semantics 
explicit.

We have, finally, an elegant way to kill the "login" page once and 
forever. Alas!

One day I hope the anti-flow/pro-action people will simply stop 
sneaking doubts and come up with real arguments on why we shouldn't 
heavily bet on the flow.

--
Stefano.

Re: [RT] Improving Sitemap and Flowscript

[Steven Noels]

Stefano Mazzocchi wrote:

If you talk to os kernel folks, they think authentication should happen 
right at TCP/IP stack level, if you talk to httpd, they will give you an 
apache module, if you talk to servlet engine folks, they will give you a 
web.xml descriptor or, if you are lucky, a servlet filter, if you talk 
to sitemap lovers, they will give you an action.
Out-of-the-blue-thought (and I had way too much wine last night): 
shouldn't this 'action-in-sitemap' thing be alleviated by an 
'orthogonal-to-the-matchers' thing in the sitemap? So that you end up 
with a section in the sitemap describing the content-generating 
artefacts, and another one listing the authentication realms, maybe 
using the same matcher-like constructs describing which portions of the 
URI space should be protected?

I'm having the slight feeling we are moving stuff into flowscript that 
can mess up good URI practices.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

DO NOT REPLY [Bug 21399] - [PATCH] Process http.nonProxyHosts in WebServiceProxyGenerator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21399

[PATCH] Process http.nonProxyHosts in WebServiceProxyGenerator

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 20271] - [PATCH] General background task manager leveraging Avalon

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20271

[PATCH] General background task manager leveraging Avalon

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|NEW



--- Additional Comments From [EMAIL PROTECTED]  2003-08-21 12:52 ---
I just have committed my own version of a scheduling component; it has some 
differences to your implementation but should basically do the same. Perhaps 
you can also have a look at it.