burtonator wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rapha�l Luta <[EMAIL PROTECTED]> writes:
>
> <snip>
>
>>This is a nice and ambitious project, but this has nothing to do with current
>>Jetspeed goals : We aim to create a portal engine, ie an application framework
>>capable of aggregating various applicative components into a single unified
>>view and provide the user with customization tools for selecting the content
>>to display and personalizing the content appearance.
>>
>
> Reptile does this... and does a lot more.
>
Show me. Where's the live demo ?
>>This is completely bogus: Programming has always been the art of manipulating
>>and transforming data using deterministic algorithms. XML just introduces a
>>new standard and very flexible syntax for manipulating data. It does not change
>>in any way the need for processing data which can be expressed in any programming
>>language you care to use.
>>
>
> No. I believe you misunderstand. The problem is with the Jetspeed API you end
> up spending all your time working with Java. With Reptile, use of Java is
> deprecated and XML is what is most important.
>
> Careful what you say. It obviously isn't "completely" bogus because Reptile is
> doing it right now. ;)
>
It just means you embed code in your transformation step, ans partly delegate
processing to XPath selector in XSL styling. This is messy and unmanageable
just like those great 1-line regular expressions hack in Perl.
You may like simple ad-hoc design that fullfill your need but don't limit
your creativity. I believe this to be a hack and prefer a more engineered
approach which provides me with a solid manageable and extensible foundation.
> It may not be possible for me to describe the advantages of this new design.
> Prior to being enlightened to the fact that Emacs was the "one true editor", no
> one in the world could have convinced me of this fact. The only way I could
> learn this was to spend some time hacking on it.
>
If you can't explain the advantages of this design, then it's certainly because
it is definitely not obvious.
>
>>>Jetspeed could not function without the Portlet API. This is especially true
>>>because a lot of Jetspeed's own UI is generated with Portlets. Reptile handles
>>>this problem with Xalan extensions. This also has the added advantage of
>>>providing Reptile with a plugin architecture which supports other languages
>>>besides Java including Python, Javascript, etc due to the IBM Bean Scripting
>>>framework.
>>>
>>>
>>You mean you want to handle programming logic within XSL stylesheets ?
>>
>
> No. Most of the complex logic is done via XSLT extension functions. Example:
>
> <xsl:value select="extension:someReallyComplexJavaFunction()"/>
>
Yeah, worse. Mixing XPath, XSL and scripts is IMO a kind of engineering
perversion. All these tools are great when used in their proper context,
but mixing them all in just FS all the way (FS: flexibility syndrome,
for those who don't know what it's about check the Cocoon archives...).
>>I think this is a dubious move at best, I'll stick to a manageable programming
>>language...
>>
>
> You already have one. Java. With Reptile you can also use Javascript, python,
> etc.
>
> ah... choice is good! :)
>
I beg to disagree, sticking to one programming language throughout a project
is more appealing to me.
>
>>Also, as you are very well aware, BSF is a Java package which can be used to
>>include scripting support in any Java application.
>>
>
> Yes but the Xalan integration is much nicer than just raw BSF.
>
LOL :)
>
>>>Another main difference is that there is no PSML. Instead we use a system
>>>of layout, control and page schemas which can produce the same output but in
>>>a much more flexible manner. > >
>>>
>>
>>Probably, a lot of systems are more flexible than PSML, the catch is to keep
>>enouch power while still offering user customization capabilities.
>>
>
> The exact same power is available with our approach and with a lot more
> flexibilty.
>
Give us some details then, I'd love to know how you handle user
controlled customization.
>>>
>>I think you have not looked at what Jetspeed provides recently and what is in
>>the works (new Portlet API).
>>
>
> I have been keeping track. I didn't just drop off the Internet :).. Just had no
> comments on Jetspeed available for the list.
>
> The new Portlet API is irrelevant because we have no equivalent under Reptile.
>
What you mean is because Jetspeed offers functionalities that can't be reproduced
under Reptile, they are not relevant ?
Come on, Kevin, drop the marketing hat, we're engineers around here if you have
nice, compelling ideas just explain them and we'll evaluate and compare. If you
don't have something tangible, just let us work and preach elsewhere.
>
>>Reptile probably provides a more evolved syndication system than the one
>>currently provided by Jetspeed. I can easily integrate this syndication engine
>>into a Jetspeed portal if so I need, they really tackle 2 different problems.
>>
>
> It is still evolving. Now that you mention it I might try to fork it off into
> an isolated component so that it is discrete and isolated from Reptile. The
> added benefit is that if the Jetspeed projects chooses to do so it can.
>
> BTW. You guys might be interested in the Panther
> (http://panther.openprivacy.org) project. It is a embedded Proxy similar to the
> Jetspeed disk cache but with a much nicer design. It is modular and can be
> plugged into Jetspeed with relative ease.
>
>
Cool.
>>Also, you try to create from scratch an XML serving environment, you'd much
>>better integrate your specific features into Cocoon, with a couple of
>>transformers and generators you would have exactly the same functionality but
>>integrated in a solid, robust serving environment.
>>
>
> Yes... I am aware, and There are a number of reasons for this. This might
> change in the future though. Just because Cocoon exists doesn't mean that one
> shouldn't consider alternative approaches.
>
> ... as per reinventing the wheel. I completely agree which is why I didn't do
> it. Cocoon has a lot of drawbacks (and a lot of advantages). Putting together
> the sequence engine was trivial and it will be easy to replace with Cocoon
> if/when we decide to.
>
Cocoon 2 is one of the best designed piece of software I've seen and I think
the Cocoon team made a fantastic job in assessing and correcting the issues
with Cocoon 1 (and they are still doing it).
Disregarding, such a stable, industrial strength serving environment because
you currently only needed 10% of the functionalities and you could implement
that easily is either lazyness (you did not want to learn how to use cocoon)
or lack of foresight (you can't imagine that you'll need the rest of the
functionalities some day).
In both case, I have strong doubts on the evolution of Reptile as a project,
especially given your track record in Jetspeed.
--
Raphael Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
