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. > > 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. > 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 :-/ > 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.] 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. 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. [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.] 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. It's better if other systems or software projects adopt these languages, and refer to them through their proper names. 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. 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 ;-). We should try to do the same thing with other parts of Cocoon, not only XSP. 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. Best regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://orion.nsr.hp.com/ (inside HP's firewall only) http://sourceforge.net/users/ovidiu/ (my SourceForge page) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
