Ovidiu Predescu wrote:
>
> On Sat, 19 Jan 2002 10:38:05 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
> > Ovidiu Predescu wrote:
> >
> > > Other than this everything else in the infrastructure is the same
> > > between the two implementations. The difference is of course, the way
> > > the pipelines are setup: in the compiled case each pipeline is setup
> > > by compiled code, running as fast as possible, while in the Scheme
> > > case, the pipeline setup is driven by the Scheme sitemap function,
> > > which should be slower than the compiled version.
> >
> > I'm curious about the trends.
> >
> > A while ago I thought that an interpreted sitemap could be as fast (or
> > even faster) than a compiled one on hotspot JVM.
> >
> > What JVM are you using? have you seen any difference in performance
> > trends between the two (the compiled sitemap should be faster at first,
> > then converging after a few thousands calls)
>
> I'm running both IBM's 1.3.0 and Sun's 1.3.1. While running on the
> same JVM, I don't see much of a difference in how the application
> performs in time. At startup both implementations are slower, but they
> improve quickly. I didn't spend much time investigating this aspect,
> so I cannot comment much on it.
Cool.
> > > For the flow language, I was thinking to name it JWebFlow. I
> > > originally thought of JavaFlow, or WebFlow, but they are both taken by
> > > some other projects/commercial companies.
> > >
> > > Any better ideas on a good name for the flow language? I'd like to
> > > hear your comments on this one.
> >
> > Hmmm, I question if we need to name it.
>
> I think we do need a name for it. I explain this below.
>
> > I mean: cocoon has the sitemap language, but we don't call it XMap or
> > XPL (extensible pipelining language) or equivalent. We simply say
> > 'sitemap' and everybody understands.
>
> Right. The fact that we don't name it explicitly, doesn't mean the
> sitemap is not a language. The implicit name for it is "Cocoon
> sitemap", probably that's why nobody came up with another one.
Yes, but it remains the fact that nobody saw the need for naming the
markup syntax something specific.
> > Now, my personal suggestion is to avoid calling the language something
> > but call the flow scripts simply 'flowmaps'.
> >
> > As we then say 'sitemap markup' we will say 'flowmap language'.
> >
> > My impression is that naming the language will give users the impression
> > they have to learn another programming language (yet another!) in order
> > to run Cocoon and get something out of it.
> >
> > Hey, this is *exactly* what happens for the sitemap, but people are
> > *much* less scared away from markup because I think the problem is with
> > syntax, not with semantics.
> >
> > that is the reason why a scheme version of the sitemap or flowmap will
> > scare the crap out of almost every user we already have!
>
> Yes, unfortunately I have to agree with you here. People don't get too
> excited when they see a language with apparently little, to no syntax
> :-/
good.
> > so, java doesn't scare people away because it uses the good-old C
> > syntax. javascript same thing.
> >
> > Now you come up with JWebFlow... ok, the user thinks: has a J on it, so
> > it must be similar to java, and that's good, but then what?
> >
> > On the other hand, the docs say: the sitemap defines the resources of
> > your site and the flowmaps define the flow and interaction between them.
> >
> > What could be easier and more elegant than that?
> >
> > so the user looks at examples and find out that the sitemap is written
> > using the XML syntax (and he'll find similar to the httpd.conf or
> > server.xml files and be pleased) and the flowmaps are writting using a
> > javascript-like syntax, cool, that's how he would have done it in his
> > dreams.
> >
> > But if you tell him: look, in order to write your flowmaps, you have to
> > learn JWebFlow... oh, shit, no, no, I have a short deadline and I'm
> > already mixing java and PHP in my site, no please, no more languages.
> >
> > See what I mean?
>
> Yep, I understand the rationale behind your point of view.
>
> However the situation is very different between the sitemap language
> and the flowmap language. The sitemap is a small "little language" for
> describing processing. [Note that "little language" is an actual term
> in computing, and refers to domain specific languages.] Traditionally
> people don't give names to such languages, unless they evolve them
> outside the context of the project they were initially used. This is
> fine usually, as you, as the developer, are concerned more about the
> language's functionality rather than evolving it outside your
> project. The risk however, and you touched on it briefly, is that
> people trying to use your project will perceive the language as
> proprietary. [The "proprietary" term is related to whether the
> language is unique to your project or not, not to whether the
> source-code of the language's implementation is open-source or not.]
yep
> On the other hand, if you reuse some existing language in your
> project, you eliminate part of the risk of being perceived as
> proprietary. So from a pragmatic point of view it's good to reuse as
> much as you can, and invent new little languages only when
> necessary.
Oh, totally. I completely share your point and couldn't probably express
it any better.
> Although there's now a large belief that every software
> project defines many little languages in its implementation. Not all
> of them have names, and perhaps the implementor is not even aware he's
> implementing a little language.
granted.
> [Related to little languages is the belief that a good programming
> language should make the task of creating little languages very
> simple. Incidentally, Scheme and Lisp-like languages, are very good at
> this with their very powerful macro system, the ability to represent
> programs as data, and interpret this data as a program, and access to
> the runtime evaluator. Other languages however, like Perl and Python,
> evolved more recently with lots of features in the ability to define
> little languages. In such languages, you can easily define your own
> little language with some careful thought and little work, which
> describes the tasks you want in higher level concepts, as opposed to
> the low level abstractions of the programming language, whatever that
> is.]
hey, careful here: while I agree that this might be good (what is the
XML model is not a way to build your own markup vocabularies and
semantics?) I also perceive the danger or Flexibility Syndrome that such
'do it yourself' languages give you.
If you make the contracts to floppy, they bend when you put too much
pressure on them.
One for all: C++ operator overloading!
> Now let's go back to the sitemap and flowmap languages we currently
> use or we'll use in Cocoon. I believe our users will benefit a lot
> more if we identify them as separate language, rather than hide them
> underneath Cocoon' shell.
Here is where I don't find myself resonating with your view.
If I were to choose between abstracting the languages so that they were
more portable and make them more usable even if this means making them
cocoon-aware, I would choose the second one.
I see your point, but I think it's theory: in practice, unless
standardized by the W3C or the JCP, it's very hard that some technology
invented in Apache will get the 'language' status and become a contract
between different implementations (look at XSP, for example)
> It's better if other systems or software projects adopt these
> languages, and refer to them through their proper names.
hmmm
> This will
> make these languages less proprietary, and easier for people to accept
> them, if they encountered them in other projects. But for this to
> happen, these languages have to have names of their own, and not be
> referred to as "Cocoon's sitemap" or "Cocoon's flowmap" languages,
> which makes them tied to Cocoon.
Ok, I agree with your view of software dynamics, but I don't think it
would be any *better* if other projects start building 'cocoon clones'
with other languages, because that would place even more rigidity on the
contracts and we are not *that* stable and we are not a recommandation
entity like W3C or JCP (and don't want to become one!)
> To give you an example from the Cocoon world, look for example at
> XSP. The fact that it was recognized earlier in Cocoon's lifetime as a
> separate language, made it adopted by AxKit. I would say this was a
> very good thing, the first step towards conquering the world ;-).
...or the first step toward killing XSP since evolution was harder since
two very-slightly overlapping communities were forced to talk together.
> We
> should try to do the same thing with other parts of Cocoon, not only
> XSP.
Knowing how XSP technology has been 'stagnating' for the last 18 months
(yes, I'm partially responsible for this, I admit!), I don't think we
are big enough to do what you propose.
This is why I would *not* be happy if other projects start to clone our
contracts and want to control their further development: I don't think
we are solid enough to do this and might tear the user community apart
and provide forks. (the fact that AxKit uses XSP is simply to avoid
reinventing the wheel: you can't make them interoperate so they are not
the same stuff!)
I have the *strong* impression that if other projects start to 'clone'
us for their use in other languages, the net result will be more
visibility, but too much for what we can currently handle!
Cocoon is a big-time R&D project: we are inventing, not implementing.
This requires time, patience and lack of pressure. If you turn your R&D
effort into a solid contract (by giving a name to it!), people will
start asking for 'stability of that contract' and the evolution will be
slowed down, or you'll be foced to fork.
In not saying that this will never happen, but there is proper timing
for everything and I think *this* is not a good time for making the
sitemap and the flowmap a contract shared by different implementations,
because that will very likely tear them apart, along with the user
communities.
> That's exactly the reason I'm trying to come up with a name for
> the "flowmap language". I believe the concepts behind it are much too
> powerful for it to be just a little language for Cocoon. For Cocoon to
> be successful in the long run, it's important to have its ideas
> adopted by other projects as well.
Key works: 'long run'.
I'm not saying that this will not happen, but I'm saying that we should
make it as hard as possible for people to clone Cocoon and rip out
contracts until we have the ability to 'fight' to keep those contracts
solid and we have a position where we have clear indication on how to
evolve and influence them.
For now, my opinion is: let's focus on development. Marketing has to
follow that.
--
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]
