JetSpeed 2

[Frans Thamura <ft...@yahoo.com>]

Tips for JetSpeed 2.

I prefer a compatibility with 1.3 version in
specification like xreg, PSML, etc..

Why do I email this to all of you?

Because there is a jetspeed 2 directory when I
download the CVS.

1.3a2 have a great improvement, I prefer make it
stable also..

Oke..

Frans

--- David Sean Taylor <da...@bluesunrise.com> wrote:
> > 
> >     http://relativity.yi.org/portal.png
> > 
> 
> I can't view the image.
> I get an error:
> 
> Cannot find server or DNS Error
>  
> 
> > -----Original Message-----
> > From: burtonator [mailto:burton@relativity.yi.org]
> > Sent: Wednesday, July 11, 2001 4:51 AM
> > To: jetspeed-dev@jakarta.apache.org
> > Cc: Reptile Mailing List
> > Subject: [LONG] The future of Jetspeed... is with
> Reptile
> > 
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > Hello.
> > 
> > I have been vacant on this mailing list for a
> while.  The 
> > reasons for this
> > absence will be explained shortly.  I would like
> to apologize 
> > in advance for the
> > controversial nature of this e-mail.
> > 
> > After creating the Jetspeed project and driving it
> to the 
> > point where it was
> > about 8 months ago, I learned a LOT about what to
> do and what 
> > not to do when
> > building a Jetspeed like application.
> > 
> > I use the term "Jetspeed like application" because
> I believe 
> > the term Portal or
> > Enterprise Information Portal has been used
> incorrectly.  A 
> > lot of people have
> > applied the term Portal to describe a
> client/server 
> > application which is behind
> > a centralized web server.
> > 
> > I do not believe this is the future of this
> technology.
> > 
> > I believe the term Portal should be redefined to
> describe a 
> > fully distributed,
> > XML centric, syndication framework with the
> addition of 
> > services such as
> > Reputation, XML based content syndication, P2P
> style 
> > functionality (node-to-node
> > caching, node-to-node syndication, HTTP layer
> which doesn't 
> > use DNS, etc),
> > micropayment integration and language translation
> services.  
> > Privacy protection
> > should also make up a significant portion of the
> project and 
> > it should support
> > distributed, nym based authentication (which can
> drive reputation).
> > 
> > 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
> > 
> > To that end, a friend (Fen Labalme) and I founded
> the 
> > OpenPrivacy project
> > (http://www.openprivacy.org) and spent the last 8
> months in 
> > research and
> > development mode trying to figure out where this
> stuff was 
> > going.  We began by
> > focusing on using Reputation to measure the
> quality of 
> > distributed resources
> > (URLs) and tried to incorporate this into
> correctly measuring 
> > privacy concerns
> > so that one can use the system without fear of the
> Orwellian 
> > issues that arise
> > from fully uniform and traceable systems.
> > 
> > If you accept my redefinition of the term Portal
> it quickly 
> > becomes clear that
> > Jetspeed won't solve these problems.  The problem
> is that 
> > Jetspeed is a Java/Web
> > application which uses XML in a limited manner. 
> The correct 
> > interpretation
> > should realize that XML is what is *most*
> important and that 
> > Java and any other
> > specific technologies are used simply to optimize
> and transform XML.
> > 
> > The Reptile project
> (http://reptile.openprivacy.org) was 
> > created to solve these
> > problems and provide an implementation of this
> technology.  
> > Since its creation
> > about a month ago the Reptile project has made
> amazing progress.  
> > 
> > - From an architecture perspective, Reptile is
> significantly 
> > different from
> > Jetspeed.  First off there is no plugin API.  The
> only way 
> > content can make it
> > into Reptile is via XML and a contentType.  That
> said 
> > developers can still use
> > Java code to produce XML and integrate it any way
> they want.  
> > 
> > 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.
> > 
> > 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.
> > 
> > We have no capability system like the Jetspeed
> capability 
> > map.  I expect this to
> > be integrated soon but it is currently at a low
> priority.  It 
> > will probably be
> > integrated into our sequence dispatch system.
> > 
> > Reptile does not use Turbine.  I have mixed
> feelings about 
> > this.  In some ways
> > Turbine is great but in others it is a hindrance. 
> Hopefully 
> > we can come up with
> > a solution to this soon.  I really feel that
> Turbine should 
> > to be split into
> > multiple projects.  Right now there is just too
> much code in 
> > one place.
> > 
> > We do have PortletControl functionality within
> Reptile but it 
> > doesn't use Java
> > and instead uses XML and a dedicated namespace.
> > 
> > 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.
> 
=== message truncated ===


=====
Let's Empowering Open Source

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org