Ovidiu Predescu wrote:
> Anyways, here's the way I see now the whole thing right now. The
> sitemap continues to be the main controlling point. However, the
> result of a matching will no longer be a pipeline, but a Scheme
> function invocation. In particular, a pipeline will be defined as a
> Scheme function.
This is an interesting concept: it would allow back compatibility as
well as back-compatible support for publishing-oriented mindsets. But
allow us to increase the functionality without turning the sitemap into
a full-blown programming language.
> The result of this is that you can have the todays pipeline concept
> unmodified, so it should be easy for people to understand how things
> work. This processing model would fit very well applications that
> publish content more or less static, which needs to be transformed in
> various ways.
>
> For more complex applications, multi-page type apps, you can hookup
> your own function that will be called once a match is performed. This
> function will implement your application high-level logic, using
> Scheme continuations. The application logic (connecting to databases,
> performing computations and so on) will be written in Java as
> normal. In Scheme you will only describe the navigation between pages,
> using the continuations paradigm.
I'm *very* interested to see the results of this, althought, IMO, there
is no portable way to implement continuations in Java, but I'd *really*
love to be proven wrong. (GNU Kawa, a scheme2java interpreter implements
continuations only locally and uses exception throwing for that, but no
global continuations are implemented)
> Each time you want to send a response back to the client, you will use
> a "send-response" function, which takes an output pipeline definition
> and an XML document to process.
Yeah, that would definately enfore the SoC between webapp logic and
screen (in Turbine terminology) production.
> We can experiment with rule based systems as well. The beauty of
> having such a high-level, interpreted language, driving the processing
> is that we can experiment with lots of ideas very easily. Since the
> whole sitemap logic is written in Scheme, it's very easy to alter it
> the way you want it.
Hmmm, I'm not thrilled by this at all: it might be good for *us*
developers to experiment with this easily (I totally agree with that),
but as I wouldn't want to turn the sitemap into a full blown programming
language and give users full power to modify it (see my past messages
against dynamic pipelines), I think we should "tune" the flow-driving
expressing logic in such a way that you have what you want, is fully
documented and you don't have to reinvent the wheel everytime.
The rule is always to give all the freedom that one needs, but nothing
more than that.
> Regarding the XML syntax of the sitemap, I actually believe it's a lot
> easier if we just have the sitemap written in Scheme
I think not. DSSSL vs. XSLT is a good example of why the lisp-like
parenthesis syntax in the document-centric world is a bad idea.
I would say the opposite: use XML even for describing the flow-driving
logic.
>, instead of
> XML. We can add new stuff much more easily than trying to invent a
> syntax in XML.
There is nothing to invent: the XML syntax is very well defined, just
like the Scheme one. What we have to invent is a 'semantic', but the
same thing must be done in Scheme.
As I wrote in a previous message, it is possible to map the XML syntax
with the Scheme syntax in a very simple way. This shows that there is no
syntax limitation, but it's just a matter of personal taste.
> Here's how a sample sitemap would look like in the
> Scheme syntax:
>
> (sitemap
> (define-pipeline docbook-html (dir filename)
> (generate (concat dir filename))
> (xslt "docbook-html.xsl"))
>
> (match "/myapp/*/*.xml"
> (pipeline docbook-html))
>
> (match "/app2/*/*.pdf"
> (pipeline
> (generate (concat dir filename))
> (xslt "docbook-html.xsl")))
> )
Sure is less verbose than the XML syntax, no question about it, but is
equally effective for users grown up with HTML tags? I don't think so.
Besides, without an editor, it's almost impossible to write Scheme
without syntax errors due to mismatched parenthesis, something that is
much less frequent with XML due to increased verbosity.
For example, try to finish the following strings so that the first is
well-formed Scheme and the second is well-formed XML:
(a (b (c (d (e f) (g (i l)
<a>
<b>
<c>
<d>
<e>f</e>
<g>
<i>l</i>
The first is much more compact, no question about it, but was it easier
to write without some editing help? (use VI or notepad, don't cheat with
Emacs)
Sure, you might say, I've placed everything in a single line, so it
would be fair to finish the version below where indeting helps you
counting the right
(a
(b
(c
(d
(e f)
(g
(i l)
but then again, the result is
(a
(b
(c
(d
(e f)
(g
(i l)
)
)
)
)
)
or, as some college teachers would suggest you to write
(a
(b
(c
(d
(e f)
(g
(i l)
) ; end g
) ; end d
) ; end c
) ; end b
) ; end a
in order to 'contextualize' the ending parenthesis.
Well, in this case, I don't see big difference between the above and the
XML equivalent
<a>
<b>
<c>
<d>
<e>f</e>
<g>
<i>l</i>
</g>
</d>
</c>
</b>
</a>
which I find cleaner and more elegant, since it includes in the syntax
the 'contextualization' of the closing causes used in the syntax.
It might appear as unnecessary verbosity at first, but, IMO, results in
code much easier to read.
Warning: I'm not advocating that the XML syntax is good for writing
general programming language, I think the exact opposite, expecially
since you have to escape the '<','>','&' characthers that are *very*
frequent for programming languages.
But I don't think that a scheme-version of the sitemap would be of any
good. Rather, I think it would ultimately hurt both the acceptance of
the sitemap concept, its readability and its usefullness as a new
instrument for web-app design.
> "sitemap" above is just a Scheme function that reads its arguments and
> generates another function to match a request against the specified
> patterns.
IMO, this only proves that it would be easier and more immediate to
transform the sitemap document into Schema syntax than it would be to
java syntax. In fact, it might be a good solution for the interpreted
sitemap: transform it to Scheme and let the scheme interpreter interpret
it instead of writing our own.
> Another side-effect of executing "sitemap" is that all the
> "pipeline" functions will setup in the Java space the transformers
> objects according to the description. The serialization process could
> be added automatically by the "match" functions, if no serializer has
> been defined. Similarly one can think of lots of possible semantics
> associated with the above description.
This is behavioral and is nothing related to the syntax used. In fact,
we all agreed that an interpreting engine for the sitemap semantics
would allow faster development cycles and probably allow to reduce
verbosity, as you state above.
But please understand that this is not related to the syntax used to
describe the sitemap semantics: one concern is the syntax, another
concern is the semantic.
In fact, we could imagine to have two different syntaxes for the same
semantic, just like you can have two different styles for the same
content.
> Of course, he sitemap file should contain no Scheme code, only the
> sitemap description. Everything else should be in separate Scheme
> files.
Which is good, since the concern of describing sitemap-related behaviors
and the one of describing logic-specific behavior should be kept well
separated.
> I don't think the Scheme sitemap syntax is that bad, but I'd be
> curious to know what others think of it.
Now you know :)
> I'll let you know what's the progress on my work. If anyone is
> interested in seeing intermediate results, I can check the code in the
> scratch-pad CVS area.
Yeah, please do.
> I'm really excited about the new possibilities, so I'm going back to
> coding some more ;-)
I want to clarify that I am as well.
I personally think that using a Scheme-like syntax for the sitemap would
be a *very* *bad* idea. Equivalent of shooting ourselves in the foot or,
worse, create forking friction in the project.
I'd vote -1 on this proposal.
For the web-app flow-driving logic, the use of an XML syntax might be
overwelming, expecially since escaping '<' with '≶' totally destroys
readability. So I'm open to suggestions on that side.
Still, it might be understood that the concer of coming up with the
required semantics and the syntax used to describe it are two different
concerns and must be kept well separated: in theory, there is nothing
that prevents us from writing this flow-driving logic in java and add
continuations support transparently, for example
public class Addition extends WebApp {
public execute(Environment env) {
Results res = env.input("/webapps/addition/firstAddend");
int a = res.getInt("addend");
env.context.add("firstAddend");
res = env.input("/webapps/addition/secondAddend");
int b = res.getInt("addend");
env.context.add("secondAddend",b);
env.content.add("result",new Integer(a + b));
env.output("/webapps/additon/result");
}
}
and let Cocoon take care of the continuations.
Anysay, syntax aside, the only portable way I see for implementing these
types of continuations with java is a massive use of threads. This means
that each running web-app (that is, each connected user if we ignore
window-cloning), must have a stopped thread on the server side awaiting
to be resurrected.
Now: writing a webapp using page-driven programming is inherently *MUCH*
harder (unless one totally ignores the issues with the back-button and
the window-cloning, which is what normally happens), but at the very
least, doesn't require "ONE THREAD PER LIVE SESSION"!!!, something that
would bring on its knees even the most scalable JVM implementation. Not
even talking about those OSes where thread==process (like Linux).
The other solution (which is much more scalable) is to implement some
native code that is able to save the complete state of the thread in
some way, then free the thread to be used for other things. When the
request comes, this thread-state data is used to 'resurrect' the thread
from the point it was stopped (which is the same concept of
'call-with-continuations' in Scheme).
Scheme shows it's possible to achieve, but for sure, this is not
something the current Java language includes as a first-class citizen
(and there are no JSR that proposed this, AFAIK)
The best solution would be to add some continuation-based thread
construction mechanism to Java, but this would require hard-core native
code and I personally wouldn't even know where to start :(
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
