-----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.
<snip>
> > They say a picture is worth a thousand words and I believe this describes the
> > type of power this technology could give to the individual.
> > http://relativity.yi.org/portal.png
> >
>
>
> Your host does not have DNS resolution.
ug... my DNS server seems to be having problems :(
<snip>
> 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 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.
> > 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()"/>
> 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! :)
> 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.
> > 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.
> > Due this new design I believe that it is currently more advanced that Jetspeed.
> > The main advantage that Jetspeed provides is that people are currently using it
> > right now and it is stable. I would invite everyone here to take a look at
> > Reptile and see what they think.
> >
>
> 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.
> 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.
> 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.
The only think Reptile does which serves XML is
- - get a TrAX transformer
- - transform an XML document
- - spit it out over the servlet.
... pretty easy :)
Kevin
- --
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
Linux. The *only* Operating System you will ever need.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE7TMyNAwM6xb2dfE0RAlt/AKDSSL5XjP/VnM0DF6idS9YRxLdLxQCeMMaa
De9EGnHSLBCh/CcsoNINgqk=
=lKrX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
