portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: [LONG] The future of Jetspeed... is with Reptile
Date Wed, 11 Jul 2001 16:34:20 GMT
>     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
> 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.
> Reptile still has a bit of growing to do.  CVS is currently 
> very stable but I
> have refrained from doing a 0.0.1 release due to that fact 
> that I want to
> incorporate more Reputation technology and features.  
> Hopefully these will start
> landing over the next month and we will have a 0.0.1 release shortly.
> Thank you.
> Kevin
> Resources
>     - website: http://reptile.openprivacy.org/
>     - screenshots: http://reptile.openprivacy.org/screenshots
>     - current status http://reptile.localhost/features.shtml
>     - snapshots http://www.openprivacy.org/nightlies
> - -- 
> Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, 
> burtonator@acm.org )
>         Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 
> 73488596 
> Free Software!  Join the Software Jihad!
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
> iD8DBQE7TD25AwM6xb2dfE0RAldvAKCUAJzFtK5PSI9nrKNDpkwU+5rk9gCdF5tM
> E3+l+1RxiYNAd7oZ7Rx12GY=
> =0USG
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

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

View raw message