You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by burtonator <bu...@relativity.yi.org> on 2001/07/11 13:51:21 UTC
[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.
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!
-----BEGIN PGP SIGNATURE-----
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
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: [LONG] The future of Jetspeed... is with Reptile
Posted by Anil Shinde <as...@cisco.com>.
Me too, Not able to access the URL.
-Anil
At 09:34 AM 7/11/01 -0700, you 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.
> >
> > 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!
> >
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > 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
> > -----END PGP SIGNATURE-----
> >
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [LONG] The future of Jetspeed... is with Reptile
Posted by burtonator <bu...@relativity.yi.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raphaël Luta <ra...@networks.groupvu.com> writes:
> burtonator wrote:
>
> >
> >>>Reptile does this... and does a lot more.
> >>>
> >>Show me. Where's the live demo ?
> >>
> > Right now I haven't focused on building a client-server demo. Reptile can
> > certainly support this but it is not our focus. Right now Reptile is basically
> > a P2P application which you run locally.
> > You can either look at the screenshots or download the build and run
> > "reptile-startup.sh"
>
> OK, so Reptile does not answer the same need that Jetspeed but try to create
> a new usage paradigm using P2P.
Reptile can be used like Jetspeed if one wanted to do so. It is just something
that we are not specifically putting time into.
<snip>
> > And... why? There is nothing different with this approach when compared to
> > Velocity, JSP, etc.
> >
>
> Granted for JSP. The whole point of Turbine/Velocity is to properly separate
> what should be the realm of the developer and what should be the realm of the
> designer (using MVC pattern). The same can be said of Cocoon which specifically
> tries to enforce separation of content between teams of different skills.
>
> If you don't see why it's different from your approach, then I think you'll
> soon find out in a couple of months when you'll try to incorporate new ideas
> in Reptile or if you ever try to explain and train people to use your Product.
Reptile does follow a MVC pattern. It uses multiple stylesheets to provide
this. One acts as as am model the other a view an yet another a controller.
We are almost 100% on par with the Cocoon viewpoint of MVC vs the Velocity
viewpoint.
<snip>
> Yes, I disagree that choice is good by nature. There are some cases where it's
> sensible to provide choice and some where it just leads to unnecessary
> complications and does not provide real benefits.
Balance is what is most important. Too much choice and you have a situation
resembling chaos. Too little choice and a system is to rigid to support
innovation.
<snip>
> OK. Just 2 things:
> - the basic approach is the same than PSML or Cocoon aggregation
not the same but similar.
> - you have hard-coded your layout policy choice (left/right/layer) in
> your customizer choice. If you want to add a new column, you must rewrite
> a customizer;
No... just provide an additional one.
> if you want to allow the user to edit the layer colors, yet
> another rewrite;
No... another stylesheet.
> if you want to edit a WML layout, yet another rewrite...
No. I believe that WML and HTML are incompatible. We would just say
"hey... see you are using WAP. Since this is the first time you are using the
system, here are your subscriptions. Please organize them best for you WAP
device."
<snip>
> Except that doing this is Java can also abstract you from the persistence
> mechanism and can provide you with caching capabilities, transactional
> security, etc...
We get that in Reptile. Remember that Reptile still uses Java :)
<snip>
> Yeah, I've discussed this extensively at last ApacheCon Europe with Ingo's team
> and XO3 people, and I think this is a very appealing solution; however proper
> implementation of this is quite involved if you want your system to support
> arbitrary source DTD and your data source to be rendered in arbitrary output
> format.
It is already somewhat done in Reptile. Basically it keeps track of the content
type of the input source, say RSS. We then have a mapping system where you can
say "ok, I have RSS and I need XHTML" and it gives it to you. Of you can
request WML, etc.
<snip>
> Not as such, I need separation of concern in order to break responsabilities
> between different members of a team.
Which is one of the cool things of our design. Since everything is essentially
MVC, If I want to implement some crazy procedure, say db persistence, I just
put it into the model level stylesheets. If you want to tweak some HTML just
add it within the view level stylesheets.
<snip>
> Agreed there, but to make an analogy, I still find strange that people start
> writing crappy lite HTTP servers when they could just embed the well-tested,
> efficient and supported Apache httpd and customize to their need...
I have certainly held this view in the past and I think it is a valid one. The
Open Source Development Model doesn't work when people aren't cooperating. My
current failure to use Cocoon is not because I don't want to cooperate and is
only out of technical concern.
We will see how it works out... I fully evaluated this when I first stated
Reptile but decided to remain pragmatic.
> >>In both case, I have strong doubts on the evolution of Reptile as a project,
> >>especially given your track record in Jetspeed.
> >>
> > hm... my track record huh? Jetspeed wouldn't even exist without my "track
> > record".
>
> It also would have died.
It would only have died if I didn't have the foresight to Open Source it. Don't
you see this as a proof of concept that Open Source works! :)
> > Regardless of your doubts, I believe that Reptile is the future. I can
> > implement *whole* subsystems in hours that would take weeks with another
> > architecture.
>
> Good luck with your project then, I'm definitely looking forward to your
> first release.
Thanks...
I believe that there these philosophy issues are very valid. We don't have to
agree on everything but we can at least cooperate.
I am trying to keep all the work under OpenPrivacy *very* moduler. The Panther
proxy component could be used within Jetspeed with relative ease (dual license
BSD/GPL). I believe it is somewhat cleaner than the disk cache I wrote within
Jetspeed.
There is also a project named HTParser which parses out HTML for titles and
descriptions. The problem is that a lot of RSS channels don't include
<description> elements and their content is significantly less usefull. With
this mechanism we can try to guess what the content is.
The cool thing is that it can start off scrict by finding out the description
from the HTTP meta convent "description" but if this doesn't exist (or is too
short) we can failover to using the body of the HTML.
... right now it just use META tags and works on about 60%. The remaining 40%
is where most of the work will come from but it should be possible with very
rare false alarms.
Take care.
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
Hiroshima 1945, Czernobyl 1986, Windows 2000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE7TcIUAwM6xb2dfE0RApA6AJwJCQIvzj8uWFn0hBKyElY94X3hoACgxhgr
UN2S61j2l2hKeNRw9W/Q5JE=
=qd3F
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: Adding External
Posted by David Sean Taylor <da...@bluesunrise.com>.
Don't use the HTML portlet for external websites.
The HTML portlet is for local content.
For external content, try the WebPagePortlet
> -----Original Message-----
> From: Anthony Smith [mailto:anthony.smith@fedex.com]
> Sent: Thursday, July 12, 2001 7:52 AM
> To: jetspeed-dev@jakarta.apache.org
> Subject: Adding External
>
>
> When I add an entry to my jetspeed-config.jcfg file, and the
> portlet comes
> up it does some strange things. On some no, images appear, on
> external links
> that require a login, it gives an error. On an external link
> that point to a
> directory, the directory pops up but the links in the
> directory dont work?
>
> When I do an external link utside of my intranet it does not
> showup at all.
>
> Example:
>
> <portlet-entry type="ref" parent="HTML" name="Test1">
> <url>http://www.yahoo.com</url>
> <meta-info>
> <title>Link Test</title>
> </meta-info>
> </portlet-entry>
>
>
> ---------------------------------------------------------------------
> 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
Adding External
Posted by Anthony Smith <an...@fedex.com>.
When I add an entry to my jetspeed-config.jcfg file, and the portlet comes
up it does some strange things. On some no, images appear, on external links
that require a login, it gives an error. On an external link that point to a
directory, the directory pops up but the links in the directory dont work?
When I do an external link utside of my intranet it does not showup at all.
Example:
<portlet-entry type="ref" parent="HTML" name="Test1">
<url>http://www.yahoo.com</url>
<meta-info>
<title>Link Test</title>
</meta-info>
</portlet-entry>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [LONG] The future of Jetspeed... is with Reptile
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
burtonator wrote:
>
>>>Reptile does this... and does a lot more.
>>>
>>Show me. Where's the live demo ?
>>
>
> Right now I haven't focused on building a client-server demo. Reptile can
> certainly support this but it is not our focus. Right now Reptile is basically
> a P2P application which you run locally.
>
> You can either look at the screenshots or download the build and run
> "reptile-startup.sh"
>
OK, so Reptile does not answer the same need that Jetspeed but try to create
a new usage paradigm using P2P.
>
>>>>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 are certainly entitled to your opinion. I think it is a narrow view though.
>
Time and usage will tell.
>>>>>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.
>>
>
> And... why? There is nothing different with this approach when compared to
> Velocity, JSP, etc.
>
Granted for JSP. The whole point of Turbine/Velocity is to properly separate
what should be the realm of the developer and what should be the realm of the
designer (using MVC pattern). The same can be said of Cocoon which specifically
tries to enforce separation of content between teams of different skills.
If you don't see why it's different from your approach, then I think you'll
soon find out in a couple of months when you'll try to incorporate new ideas
in Reptile or if you ever try to explain and train people to use your Product.
>
>>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...).
>>
>
> Let me put it this way. I believe that I have made more progress with Reptile
> than my entire time I worked with Jetspeed.
>
Fair enough.
>
> You disagree that choice is good! OK.
>
> Reptile as an engine will stick to 100% Java. Users/admins can write anything
> they want. This is where choice comes in.
>
Yes, I disagree that choice is good by nature. There are some cases where it's
sensible to provide choice and some where it just leads to unnecessary
complications and does not provide real benefits.
>> > >>>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.
>>
>
> Sure.
>
> Essentially we start with an XML layout file. This file contains content
> positioning information:
>
> <content location="resource:/xml/users/default/news.rss"
> contentType="http://purl.org/rss/1.0/">
>
> <position column="left" layer="Home"/>
>
> </content>
>
> In order to change the position of this file within the Portal all we setup a
> new control which reads this position information (all via XSLT) and provides a
> quick HTML form layout.
>
> The user then selects right or left and the column he wants to have this control
> on. After that we invoke an action on the server (similar to the way Turbine
> handles actions) and invoke a short XSLT to make any changes and then serialize
> the output into the source XML file.
>
> When the user goes back to the page after the post everything is taken care of.
>
OK. Just 2 things:
- the basic approach is the same than PSML or Cocoon aggregation
- you have hard-coded your layout policy choice (left/right/layer) in
your customizer choice. If you want to add a new column, you must rewrite
a customizer; if you want to allow the user to edit the layer colors, yet
another rewrite; if you want to edit a WML layout, yet another rewrite...
> This would be a *really* ugly mess if it was done in Java. You would have to
> write a SAX/DOM hack which reads in the content and serializes it to XML. With
> a stylesheet we can do this in about 4 lines of functional code and 20 lines for
> the whole file.
>
Except that doing this is Java can also abstract you from the persistence
mechanism and can provide you with caching capabilities, transactional security,
etc...
>
>>What you mean is because Jetspeed offers functionalities that can't be reproduced
>>under Reptile, they are not relevant ?
>>
>
> There is no plugin API under Reptile. Content is generated via XSLT sequence
> system. If you want to add a plugin, lets say that runs a search of a database,
> you would right a Xalan extension and collect the output from the search.
>
> stylesheet1.xsl (connect to database via java extensions when given a
> 'search-query' param>
>
> OUTPUT:
>
> <search-result>
>
> <entry>Foo</entry>
> <entry>Bar</entry>
>
> </search-result>
>
> stylesheet2-xsl (handles providing device specificy rendering of this content)
>
> <dc:title>My Jetspeed plugin analogy</dc:title>
>
> <control:body>
>
> Found the following results:
>
> 1. Foo<br/>
>
> 2. Bar<br/>
>
> </control:body>
>
> This is for "plugin" content. The rest of Reptile will apply a controller.xsl,
> control.xsl and a page.xsl which provides the necessary UI to for the whole
> page.
>
Yeah, I've discussed this extensively at last ApacheCon Europe with Ingo's team
and XO3 people, and I think this is a very appealing solution; however proper
implementation of this is quite involved if you want your system to support
arbitrary source DTD and your data source to be rendered in arbitrary output
format.
Right right, reptile seems to assume the administrator control other all the
stylesheets and DTD.
>
>>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.
>>
>
> Does the above not work for you?
> <snip>
>
Not as such, I need separation of concern in order to break responsabilities
between different members of a team.
>>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).
>>
>
> It just boils down to math. The Reptile stylesheet framework is 3 .java files.
> Maybe 50 - 60 functional lines of code. It does what we need it to do and it
> does so very well IMO.
>
> ... nuf said.
>
Yes, I understand. It's a development taylored to your need, not a product.
> Again. I like Cocoon and I *certainly* have no problems with it. Cocoon just
> needs to just itself just like every other technology in the world.
>
> Sorry... I fail to believe that a solution is correct just because it comes from
> Apache.
>
Agreed there, but to make an analogy, I still find strange that people start
writing crappy lite HTTP servers when they could just embed the well-tested,
efficient and supported Apache httpd and customize to their need...
>
>>In both case, I have strong doubts on the evolution of Reptile as a project,
>>especially given your track record in Jetspeed.
>>
>
> hm... my track record huh? Jetspeed wouldn't even exist without my "track
> record".
>
It also would have died.
> Regardless of your doubts, I believe that Reptile is the future. I can
> implement *whole* subsystems in hours that would take weeks with another
> architecture.
>
Good luck with your project then, I'm definitely looking forward to your
first release.
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [LONG] The future of Jetspeed... is with Reptile
Posted by burtonator <bu...@relativity.yi.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raphaël Luta <ra...@networks.groupvu.com> writes:
> burtonator wrote:
<snip>
> > Reptile does this... and does a lot more.
>
> Show me. Where's the live demo ?
Right now I haven't focused on building a client-server demo. Reptile can
certainly support this but it is not our focus. Right now Reptile is basically
a P2P application which you run locally.
You can either look at the screenshots or download the build and run
"reptile-startup.sh"
> >>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 are certainly entitled to your opinion. I think it is a narrow view though.
> You may like simple ad-hoc design
It is neither ad-hoc nor simple.
> 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.
Good... then use Reptile. :)
> > 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.
>
I have explained but I don't think you understand.
> >>>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.
And... why? There is nothing different with this approach when compared to
Velocity, JSP, etc.
> 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...).
Let me put it this way. I believe that I have made more progress with Reptile
than my entire time I worked with Jetspeed.
> >>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.
You disagree that choice is good! OK.
Reptile as an engine will stick to 100% Java. Users/admins can write anything
they want. This is where choice comes in.
> >
> >>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 :)
Why? I have you read up on the Xalan extensions stuff or played with it?
Really cool! :)
> > >>>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.
Sure.
Essentially we start with an XML layout file. This file contains content
positioning information:
<content location="resource:/xml/users/default/news.rss"
contentType="http://purl.org/rss/1.0/">
<position column="left" layer="Home"/>
</content>
In order to change the position of this file within the Portal all we setup a
new control which reads this position information (all via XSLT) and provides a
quick HTML form layout.
The user then selects right or left and the column he wants to have this control
on. After that we invoke an action on the server (similar to the way Turbine
handles actions) and invoke a short XSLT to make any changes and then serialize
the output into the source XML file.
When the user goes back to the page after the post everything is taken care of.
Everything is then updated and saved without any problem.
This would be a *really* ugly mess if it was done in Java. You would have to
write a SAX/DOM hack which reads in the content and serializes it to XML. With
a stylesheet we can do this in about 4 lines of functional code and 20 lines for
the whole file.
> What you mean is because Jetspeed offers functionalities that can't be reproduced
> under Reptile, they are not relevant ?
There is no plugin API under Reptile. Content is generated via XSLT sequence
system. If you want to add a plugin, lets say that runs a search of a database,
you would right a Xalan extension and collect the output from the search.
stylesheet1.xsl (connect to database via java extensions when given a
'search-query' param>
OUTPUT:
<search-result>
<entry>Foo</entry>
<entry>Bar</entry>
</search-result>
stylesheet2-xsl (handles providing device specificy rendering of this content)
<dc:title>My Jetspeed plugin analogy</dc:title>
<control:body>
Found the following results:
1. Foo<br/>
2. Bar<br/>
</control:body>
This is for "plugin" content. The rest of Reptile will apply a controller.xsl,
control.xsl and a page.xsl which provides the necessary UI to for the whole
page.
> 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.
Does the above not work for you?
<snip>
>
> 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).
As do I!
> 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).
It just boils down to math. The Reptile stylesheet framework is 3 .java files.
Maybe 50 - 60 functional lines of code. It does what we need it to do and it
does so very well IMO.
... nuf said.
Again. I like Cocoon and I *certainly* have no problems with it. Cocoon just
needs to just itself just like every other technology in the world.
Sorry... I fail to believe that a solution is correct just because it comes from
Apache.
> In both case, I have strong doubts on the evolution of Reptile as a project,
> especially given your track record in Jetspeed.
hm... my track record huh? Jetspeed wouldn't even exist without my "track
record".
Regardless of your doubts, I believe that Reptile is the future. I can
implement *whole* subsystems in hours that would take weeks with another
architecture.
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
For great justice.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE7TXuAAwM6xb2dfE0RAr6LAJ4hHPuHK6XNEWEyYZJI4d40COniBwCglIjb
o1IF1mYkgujbJfsQbs/lKw0=
=iusJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [LONG] The future of Jetspeed... is with Reptile
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
burtonator wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Raphaël Luta <ra...@networks.groupvu.com> 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 - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [LONG] The future of Jetspeed... is with Reptile
Posted by burtonator <bu...@relativity.yi.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raphaël Luta <ra...@networks.groupvu.com> 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 ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [LONG] The future of Jetspeed... is with Reptile
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
burtonator wrote:
>
> 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 know that time flies by, but you dropped of the project one year ago...
> 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).
>
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.
Content Management is not something we're trying to solve because there are
already many projects tackling this issue from different perspectives (Slide,
Prowler, etc...) and as far as I can see, Reptile is just yet another with
buzzword P2P, XML and Privacy angle.
> 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.
> 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.
>
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.
> 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 ?
I think this is a dubious move at best, I'll stick to a manageable
programming language... Also, as you are very well aware, BSF is a Java package
which can be used to include scripting support in any Java application.
> 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.
> 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). 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.
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.
Why reinvent the wheel ?
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Not. (was: Re: [LONG] The future of Jetspeed... is with Reptile)
Posted by Frans Thamura <ft...@yahoo.com>.
Dear Kevin, you got a openprivacy.org email, are you
the founder??? and do you a founder of jetspeed???
I don't understand the lic very well, because in my
country lic is not anything, almost of us can pirate
the software even the most restricted software, so I
am not care of this. All of you may be the best.
I am playing around with JetSpeed, and I like because,
the personalization feature, and free.. of course..
Open Source, I think JetSpeed 2.0 or not, I prefer if
OpenPrivacy project is better, make it easy to
understand, and easy to implement.
Man.. you are still working in a small part of
project. I am involve in integration project from B2B
project to ERP integration, all the Open Source code
is still small part of it, and with you "BEST" code,
you are still small part of it.
I don't know OpenPrivacy is better or not, I think if
you can integrate you code with JetSpeed (that will be
the best), I think this is better, that why the Open
Souce community exist now, I think, I love sharing my
knowledge better than tell to everyone, my project is
better, or may be you can make a replacement. Idea is
good, but integration is another issue, eBusiness is
another issue also.
Frans
__________________________________________________
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
Re: actual cvs source not running?
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
Santiago Gala wrote:
>
> Better than this, (I got it), I'm committing a change to the
> CastorPsmlManagerService.
>
> The problem was funny: "/WEB-INF/psml" is *not* absolute under Windows
> (as per java specification, an absolute path in Windows needs the drive
> letter), but it *is* absolute under Unix, so the test:
>
> if( !rootDir.isAbsolute()) was giving different results in both platforms.
> I have chaged it to if( !rootDir.exists() ) so that now, if the root
> does not exist, is taken as context-relative, else it is created.
>
> I'll be commiting right now. It can take a while, as I'm using GPRS + my
> mobile phone from my parent's house in the beach, and the connection is
> flaky.
>
Thanks Santiago :)
It's lucky we don't all use the same setup... ;P
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: cvs access for Paul Spencer
Posted by Stan Pinte <st...@wanadoo.be>.
At 19:00 30/07/2001 -0700, you wrote:
>I've been working with Paul Spencer on the Jetspeed documentation, and I
>think he's doing a great job of it.
>I'd like to recommend him as a Jetspeed committer, so he continue with his
>work on making frequent and valuable contributions to the documentation.
>I believe Paul is committed to working on Jetspeed, and will be an excellent
>addition to the team.
>
>+1
I also read the doc, which proved to be very useful.
As someone not yet involved, I vote symbolically.
+1
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Stanislas Pinte
Computer Consultant
Sales Director
Alto Software
20 Pl St Jacques
B-4000 Liège
Tel+Fax: +32 -(0)4 221 35 08
GSM: +32 -(0)478 57 61 80
web: http://www.altosw.be
email: stan@altosw.be
Re: actual cvs source not running?
Posted by Paul Spencer <pa...@mikon.com>.
Dave,
I have been using 3.3-m3 for a month with Jetspeed and Cocoon 1.8.3-dev.
It has been stable, but I have not exercised, or loaded, it that much.
Paul Spencer
Dave Carlson wrote:
>
> Thanks, Paul. I did briefly test tomcat 3.3-m4 and saw the different
> structure within its /lib directory. But because I'm preparing a production
> site, I was concerned about its pre-beta status. I know that it is now at
> 3.3-b1. (Although planning to deploy an alpha Jetspeed is still within my
> tolerance for chaos :-)
>
> I haven't had time to search the tomcat mail lists, but does anyone have an
> informed opinion on the general stability of tomcat 3.3 and/or 4.0 for use
> with Jetspeed?
>
> -- Dave
>
> ----- Original Message -----
> From: "Paul Spencer" <pa...@mikon.com>
> To: <je...@jakarta.apache.org>
> Sent: Thursday, August 02, 2001 12:23 PM
> Subject: Re: actual cvs source not running?
>
> > Dave,
> > Tomcat v3.3 and 4.0 have made a lot of progress in solving this
> > problem. When using Tomcat v3.2 with Jetspeed and Cocoon, I had to use
> > two instance of Tomcat. With Tomcat 3.3, all jars can be place in
> > application specific lib directories while using the same instance of
> > Tomcat.
> >
> > Paul Spencer
> >
> > Dave Carlson wrote:
> > >
> > > Thanks, I fixed this one. It was caused by a copy of the saxon.jar XSLT
> > > processor in the tomcat lib, in addition to jaxp, xerces and xalan. It
> seems
> > > that jetspeed worked on windows because the tomcat startup script used the
> > > file order on windows when assembling the CLASSPATH, which put saxon.jar
> last.
> > > Whereas the tomcat start script on Linux assembled a CLASSPATH with jars
> in
> > > alphabetical order, which put saxon.jar before xerces and xalan.
> > >
> > > I need saxon for another application running in tomcat, but due to
> classloader
> > > issues, I am forced to put saxon.jsr in the tomcat classpath instead of in
> the
> > > other application's webapps lib. saxon.jar must be in the same
> classloader as
> > > jaxp.jar (at least, that appears to be the root cause).
> > >
> > > These conflicts between different XML parsers and different versions is
> easily
> > > the biggest issue in app server deployment...
> > >
> > > Thanks,
> > > Dave
> > >
> > > ----- Original Message -----
> > > From: "Santiago Gala" <sg...@hisitech.com>
> > >
> > > > >The only error remaining is this in lieu of any content in any RSS
> portal
> > > > >(e.g. within Apache Jetspeed on the default home page):
> > > > >problem in SAX transform: javax.xml.transform.TransformerException:
> > > > >ProxyEmitter.startDocument(): no underlying emitter provided
> > > > >
> > > > >Any ideas?
> > > > >
> > > > I don't have this problem. I think it is due to different versions of
> > > > TRAX/JAXP around.
> > > >
> > > > One think I use to do is to remove parser.jar and jaxp.jar from the
> > > > tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
> > > > remove from jetspeed distribution depending on tomcat version).
> > > >
> > > > I will try to find if it is this reason when I have a machine back (I
> > > > have been travelling, I'm supposed to be back home soon.)
> > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: actual cvs source not running?
Posted by Dave Carlson <dc...@ontogenics.com>.
Thanks, Paul. I did briefly test tomcat 3.3-m4 and saw the different
structure within its /lib directory. But because I'm preparing a production
site, I was concerned about its pre-beta status. I know that it is now at
3.3-b1. (Although planning to deploy an alpha Jetspeed is still within my
tolerance for chaos :-)
I haven't had time to search the tomcat mail lists, but does anyone have an
informed opinion on the general stability of tomcat 3.3 and/or 4.0 for use
with Jetspeed?
-- Dave
----- Original Message -----
From: "Paul Spencer" <pa...@mikon.com>
To: <je...@jakarta.apache.org>
Sent: Thursday, August 02, 2001 12:23 PM
Subject: Re: actual cvs source not running?
> Dave,
> Tomcat v3.3 and 4.0 have made a lot of progress in solving this
> problem. When using Tomcat v3.2 with Jetspeed and Cocoon, I had to use
> two instance of Tomcat. With Tomcat 3.3, all jars can be place in
> application specific lib directories while using the same instance of
> Tomcat.
>
> Paul Spencer
>
> Dave Carlson wrote:
> >
> > Thanks, I fixed this one. It was caused by a copy of the saxon.jar XSLT
> > processor in the tomcat lib, in addition to jaxp, xerces and xalan. It
seems
> > that jetspeed worked on windows because the tomcat startup script used the
> > file order on windows when assembling the CLASSPATH, which put saxon.jar
last.
> > Whereas the tomcat start script on Linux assembled a CLASSPATH with jars
in
> > alphabetical order, which put saxon.jar before xerces and xalan.
> >
> > I need saxon for another application running in tomcat, but due to
classloader
> > issues, I am forced to put saxon.jsr in the tomcat classpath instead of in
the
> > other application's webapps lib. saxon.jar must be in the same
classloader as
> > jaxp.jar (at least, that appears to be the root cause).
> >
> > These conflicts between different XML parsers and different versions is
easily
> > the biggest issue in app server deployment...
> >
> > Thanks,
> > Dave
> >
> > ----- Original Message -----
> > From: "Santiago Gala" <sg...@hisitech.com>
> >
> > > >The only error remaining is this in lieu of any content in any RSS
portal
> > > >(e.g. within Apache Jetspeed on the default home page):
> > > >problem in SAX transform: javax.xml.transform.TransformerException:
> > > >ProxyEmitter.startDocument(): no underlying emitter provided
> > > >
> > > >Any ideas?
> > > >
> > > I don't have this problem. I think it is due to different versions of
> > > TRAX/JAXP around.
> > >
> > > One think I use to do is to remove parser.jar and jaxp.jar from the
> > > tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
> > > remove from jetspeed distribution depending on tomcat version).
> > >
> > > I will try to find if it is this reason when I have a machine back (I
> > > have been travelling, I'm supposed to be back home soon.)
> > >
> > > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: actual cvs source not running?
Posted by Paul Spencer <pa...@mikon.com>.
Dave,
Tomcat v3.3 and 4.0 have made a lot of progress in solving this
problem. When using Tomcat v3.2 with Jetspeed and Cocoon, I had to use
two instance of Tomcat. With Tomcat 3.3, all jars can be place in
application specific lib directories while using the same instance of
Tomcat.
Paul Spencer
Dave Carlson wrote:
>
> Thanks, I fixed this one. It was caused by a copy of the saxon.jar XSLT
> processor in the tomcat lib, in addition to jaxp, xerces and xalan. It seems
> that jetspeed worked on windows because the tomcat startup script used the
> file order on windows when assembling the CLASSPATH, which put saxon.jar last.
> Whereas the tomcat start script on Linux assembled a CLASSPATH with jars in
> alphabetical order, which put saxon.jar before xerces and xalan.
>
> I need saxon for another application running in tomcat, but due to classloader
> issues, I am forced to put saxon.jsr in the tomcat classpath instead of in the
> other application's webapps lib. saxon.jar must be in the same classloader as
> jaxp.jar (at least, that appears to be the root cause).
>
> These conflicts between different XML parsers and different versions is easily
> the biggest issue in app server deployment...
>
> Thanks,
> Dave
>
> ----- Original Message -----
> From: "Santiago Gala" <sg...@hisitech.com>
>
> > >The only error remaining is this in lieu of any content in any RSS portal
> > >(e.g. within Apache Jetspeed on the default home page):
> > >problem in SAX transform: javax.xml.transform.TransformerException:
> > >ProxyEmitter.startDocument(): no underlying emitter provided
> > >
> > >Any ideas?
> > >
> > I don't have this problem. I think it is due to different versions of
> > TRAX/JAXP around.
> >
> > One think I use to do is to remove parser.jar and jaxp.jar from the
> > tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
> > remove from jetspeed distribution depending on tomcat version).
> >
> > I will try to find if it is this reason when I have a machine back (I
> > have been travelling, I'm supposed to be back home soon.)
> >
> > >
>
> ---------------------------------------------------------------------
> 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
Re: actual cvs source not running?
Posted by Dave Carlson <dc...@ontogenics.com>.
Thanks, I fixed this one. It was caused by a copy of the saxon.jar XSLT
processor in the tomcat lib, in addition to jaxp, xerces and xalan. It seems
that jetspeed worked on windows because the tomcat startup script used the
file order on windows when assembling the CLASSPATH, which put saxon.jar last.
Whereas the tomcat start script on Linux assembled a CLASSPATH with jars in
alphabetical order, which put saxon.jar before xerces and xalan.
I need saxon for another application running in tomcat, but due to classloader
issues, I am forced to put saxon.jsr in the tomcat classpath instead of in the
other application's webapps lib. saxon.jar must be in the same classloader as
jaxp.jar (at least, that appears to be the root cause).
These conflicts between different XML parsers and different versions is easily
the biggest issue in app server deployment...
Thanks,
Dave
----- Original Message -----
From: "Santiago Gala" <sg...@hisitech.com>
> >The only error remaining is this in lieu of any content in any RSS portal
> >(e.g. within Apache Jetspeed on the default home page):
> >problem in SAX transform: javax.xml.transform.TransformerException:
> >ProxyEmitter.startDocument(): no underlying emitter provided
> >
> >Any ideas?
> >
> I don't have this problem. I think it is due to different versions of
> TRAX/JAXP around.
>
> One think I use to do is to remove parser.jar and jaxp.jar from the
> tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
> remove from jetspeed distribution depending on tomcat version).
>
> I will try to find if it is this reason when I have a machine back (I
> have been travelling, I'm supposed to be back home soon.)
>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: actual cvs source not running?
Posted by Santiago Gala <sg...@hisitech.com>.
Dave Carlson wrote:
>Thanks for your quick reply (on Sunday!). Sure enough, there was a /WEB-INF
>lurking in the root directory of my file system. Jetspeed now runs, without
>having copied the .vm files as noted earlier. Thanks!
>
>The only error remaining is this in lieu of any content in any RSS portal
>(e.g. within Apache Jetspeed on the default home page):
>problem in SAX transform: javax.xml.transform.TransformerException:
>ProxyEmitter.startDocument(): no underlying emitter provided
>
>Any ideas?
>
I don't have this problem. I think it is due to different versions of
TRAX/JAXP around.
One think I use to do is to remove parser.jar and jaxp.jar from the
tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
remove from jetspeed distribution depending on tomcat version).
I will try to find if it is this reason when I have a machine back (I
have been travelling, I'm supposed to be back home soon.)
>
>Cheers,
> Dave
>
>----- Original Message -----
>From: "Santiago Gala" <sg...@hisitech.com>
>To: <je...@jakarta.apache.org>
>
>>Yep. You will still have this error if you are running under root, as
>>the previous runs of unpatched jetspeed will have created an empty
>>directory /WEB-INF/psml in the root of your hierarchy. I had to fight
>>quite a bit against this one, as my local machine is running under a
>>"normal" user, while the remote one was running under "root". If you
>>delete (rm -Rf /WEB-INF/psml) and run again, it should run. I needed a
>>lot of time (yesterday) to notice it.
>>
>>I wonder if we should completely erase the mkdirs call, but maybe it is
>>needed when a new user is created.
>>
>>>But I also get another error before I even get to the ClassCastException.
>>>
>The
>
>>>first error is thrown when Jetspeed cannot find screens/Error. I recall
>>>
>some
>
>>>similar problems several weeks ago, so I can get around this error by
>>>
>copying
>
>>>vm/screens/html/Error.vm to vm/screens/Error.vm
>>>
>>I copied these files, but I'm not sure it is needed after the other fix.
>>Currently I have no copy of this file and my local copy is running well.
>>
>
>
>
>---------------------------------------------------------------------
>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
Re: actual cvs source not running?
Posted by Dave Carlson <dc...@ontogenics.com>.
Thanks for your quick reply (on Sunday!). Sure enough, there was a /WEB-INF
lurking in the root directory of my file system. Jetspeed now runs, without
having copied the .vm files as noted earlier. Thanks!
The only error remaining is this in lieu of any content in any RSS portal
(e.g. within Apache Jetspeed on the default home page):
problem in SAX transform: javax.xml.transform.TransformerException:
ProxyEmitter.startDocument(): no underlying emitter provided
Any ideas?
Cheers,
Dave
----- Original Message -----
From: "Santiago Gala" <sg...@hisitech.com>
To: <je...@jakarta.apache.org>
> Yep. You will still have this error if you are running under root, as
> the previous runs of unpatched jetspeed will have created an empty
> directory /WEB-INF/psml in the root of your hierarchy. I had to fight
> quite a bit against this one, as my local machine is running under a
> "normal" user, while the remote one was running under "root". If you
> delete (rm -Rf /WEB-INF/psml) and run again, it should run. I needed a
> lot of time (yesterday) to notice it.
>
> I wonder if we should completely erase the mkdirs call, but maybe it is
> needed when a new user is created.
>
> >
> >But I also get another error before I even get to the ClassCastException.
The
> >first error is thrown when Jetspeed cannot find screens/Error. I recall
some
> >similar problems several weeks ago, so I can get around this error by
copying
> >vm/screens/html/Error.vm to vm/screens/Error.vm
> >
> I copied these files, but I'm not sure it is needed after the other fix.
> Currently I have no copy of this file and my local copy is running well.
>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: cvs access for Paul Spencer
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
David Sean Taylor wrote:
> I've been working with Paul Spencer on the Jetspeed documentation, and I
> think he's doing a great job of it.
> I'd like to recommend him as a Jetspeed committer, so he continue with his
> work on making frequent and valuable contributions to the documentation.
> I believe Paul is committed to working on Jetspeed, and will be an excellent
> addition to the team.
>
> +1
>
+1
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: cvs access for Paul Spencer
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>I've been working with Paul Spencer on the Jetspeed documentation, and I
>think he's doing a great job of it.
>I'd like to recommend him as a Jetspeed committer, so he continue with his
>work on making frequent and valuable contributions to the documentation.
>I believe Paul is committed to working on Jetspeed, and will be an excellent
>addition to the team.
>
>+1
>
I was missing. +1 here.
Sorry, I was moving.
>
>
>
>---------------------------------------------------------------------
>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
Re: cvs access for Paul Spencer
Posted by Frans <ft...@yahoo.com>.
+1 for his Portlet Catalog.
Great job..
Frans
----- Original Message -----
From: "David Sean Taylor" <da...@bluesunrise.com>
To: <je...@jakarta.apache.org>
Sent: Tuesday, July 31, 2001 9:00 AM
Subject: cvs access for Paul Spencer
> I've been working with Paul Spencer on the Jetspeed documentation, and I
> think he's doing a great job of it.
> I'd like to recommend him as a Jetspeed committer, so he continue with his
> work on making frequent and valuable contributions to the documentation.
> I believe Paul is committed to working on Jetspeed, and will be an
excellent
> addition to the team.
>
> +1
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
cvs access for Paul Spencer
Posted by David Sean Taylor <da...@bluesunrise.com>.
I've been working with Paul Spencer on the Jetspeed documentation, and I
think he's doing a great job of it.
I'd like to recommend him as a Jetspeed committer, so he continue with his
work on making frequent and valuable contributions to the documentation.
I believe Paul is committed to working on Jetspeed, and will be an excellent
addition to the team.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: actual cvs source not running?
Posted by Santiago Gala <sg...@hisitech.com>.
Dave Carlson wrote:
>The fix by Santiago still does not work for me. I just did a full cvs
>checkout and rebuilt about 10 minutes ago, and I still get the same
>ClassCastException as I did before. I'm running on RedHat Linux with jvm
>1.3.0 and tomcat 3.2.3. The exception is:
>
>Horrible Exception: java.lang.ClassCastException: java.lang.String
> at
>org.apache.jetspeed.services.rundata.DefaultJetspeedRunData.getProfile(Default
>JetspeedRunData.java:237)
> at
>org.apache.jetspeed.modules.actions.JetspeedSessionValidator.doPerform(Jetspee
>dSessionValidator.java:127)
> at org.apache.turbine.modules.Action.perform(Action.java:87)
>
Yep. You will still have this error if you are running under root, as
the previous runs of unpatched jetspeed will have created an empty
directory /WEB-INF/psml in the root of your hierarchy. I had to fight
quite a bit against this one, as my local machine is running under a
"normal" user, while the remote one was running under "root". If you
delete (rm -Rf /WEB-INF/psml) and run again, it should run. I needed a
lot of time (yesterday) to notice it.
I wonder if we should completely erase the mkdirs call, but maybe it is
needed when a new user is created.
>
>But I also get another error before I even get to the ClassCastException. The
>first error is thrown when Jetspeed cannot find screens/Error. I recall some
>similar problems several weeks ago, so I can get around this error by copying
>vm/screens/html/Error.vm to vm/screens/Error.vm
>
I copied these files, but I'm not sure it is needed after the other fix.
Currently I have no copy of this file and my local copy is running well.
>
>After copying this file, I get the ClassCastException noted above. The full
>text of the first Resource exception is:
>
>Horrible Exception: org.apache.velocity.exception.ResourceNotFoundException:
>Unable to find resource 'screens/Error'
> at
>org.apache.velocity.runtime.resource.ResourceManager.getResource(ResourceManag
>er.java)
> at org.apache.velocity.runtime.Runtime.getTemplate(Runtime.java)
> at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java)
> at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java)
>rethrown as org.apache.turbine.util.TurbineException: Error rendering Velocity
>template: screens/Error: Unable to find resource 'screens/Error'
> at
>org.apache.turbine.services.velocity.TurbineVelocityService.renderingError(Tur
>bineVelocityService.java:392)
> at
>org.apache.turbine.services.velocity.TurbineVelocityService.decodeRequest(Turb
>ineVelocityService.java:356)
>rethrown as org.apache.turbine.util.TurbineException: Error rendering Velocity
>template: screens/Error: Error rendering Velocity template: screens/Error:
>Unable to find resource 'screens/Error'
> at
>org.apache.turbine.services.velocity.TurbineVelocityService.renderingError(Tur
>bineVelocityService.java:392)
> at
>org.apache.turbine.services.velocity.TurbineVelocityService.handleRequest(Turb
>ineVelocityService.java:252)
> at
>org.apache.turbine.services.velocity.TurbineVelocity.handleRequest(TurbineVelo
>city.java:109)
> at
>org.apache.turbine.modules.screens.VelocityScreen.buildTemplate(VelocityScreen
>.java:169)
> at
>org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.java:
>130)
> at org.apache.turbine.modules.Screen.build(Screen.java:99)
> at org.apache.turbine.modules.ScreenLoader.eval(ScreenLoader.java:129)
> at
>org.apache.turbine.modules.layouts.VelocityOnlyLayout.doBuild(VelocityOnlyLayo
>ut.java:98)
> at org.apache.turbine.modules.Layout.build(Layout.java:91)
> at org.apache.turbine.modules.LayoutLoader.exec(LayoutLoader.java:123)
> at org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:166)
> at org.apache.turbine.modules.Page.build(Page.java:90)
> at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:123)
>
>
>----- Original Message -----
>From: "Santiago Gala" <sg...@hisitech.com>
>
>>Better than this, (I got it), I'm committing a change to the
>>CastorPsmlManagerService.
>>
>>The problem was funny: "/WEB-INF/psml" is *not* absolute under Windows
>>(as per java specification, an absolute path in Windows needs the drive
>>letter), but it *is* absolute under Unix, so the test:
>>
>>if( !rootDir.isAbsolute()) was giving different results in both platforms.
>>I have chaged it to if( !rootDir.exists() ) so that now, if the root
>>does not exist, is taken as context-relative, else it is created.
>>
>>I'll be commiting right now. It can take a while, as I'm using GPRS + my
>>mobile phone from my parent's house in the beach, and the connection is
>>flaky.
>>
>
>
>
>---------------------------------------------------------------------
>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
Re: actual cvs source not running?
Posted by Dave Carlson <dc...@ontogenics.com>.
One additional note on my last message. The identical jetspeed.war file works
perfectly when copied to Win98 and run in tomcat 3.2.3
-- Dave
----- Original Message -----
From: "Dave Carlson" <dc...@ontogenics.com>
To: <je...@jakarta.apache.org>
Sent: Sunday, July 29, 2001 1:24 PM
Subject: Re: actual cvs source not running?
> The fix by Santiago still does not work for me. I just did a full cvs
> checkout and rebuilt about 10 minutes ago, and I still get the same
> ClassCastException as I did before. I'm running on RedHat Linux with jvm
> 1.3.0 and tomcat 3.2.3. The exception is:
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: actual cvs source not running?
Posted by Dave Carlson <dc...@ontogenics.com>.
The fix by Santiago still does not work for me. I just did a full cvs
checkout and rebuilt about 10 minutes ago, and I still get the same
ClassCastException as I did before. I'm running on RedHat Linux with jvm
1.3.0 and tomcat 3.2.3. The exception is:
Horrible Exception: java.lang.ClassCastException: java.lang.String
at
org.apache.jetspeed.services.rundata.DefaultJetspeedRunData.getProfile(Default
JetspeedRunData.java:237)
at
org.apache.jetspeed.modules.actions.JetspeedSessionValidator.doPerform(Jetspee
dSessionValidator.java:127)
at org.apache.turbine.modules.Action.perform(Action.java:87)
But I also get another error before I even get to the ClassCastException. The
first error is thrown when Jetspeed cannot find screens/Error. I recall some
similar problems several weeks ago, so I can get around this error by copying
vm/screens/html/Error.vm to vm/screens/Error.vm
After copying this file, I get the ClassCastException noted above. The full
text of the first Resource exception is:
Horrible Exception: org.apache.velocity.exception.ResourceNotFoundException:
Unable to find resource 'screens/Error'
at
org.apache.velocity.runtime.resource.ResourceManager.getResource(ResourceManag
er.java)
at org.apache.velocity.runtime.Runtime.getTemplate(Runtime.java)
at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java)
at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java)
rethrown as org.apache.turbine.util.TurbineException: Error rendering Velocity
template: screens/Error: Unable to find resource 'screens/Error'
at
org.apache.turbine.services.velocity.TurbineVelocityService.renderingError(Tur
bineVelocityService.java:392)
at
org.apache.turbine.services.velocity.TurbineVelocityService.decodeRequest(Turb
ineVelocityService.java:356)
rethrown as org.apache.turbine.util.TurbineException: Error rendering Velocity
template: screens/Error: Error rendering Velocity template: screens/Error:
Unable to find resource 'screens/Error'
at
org.apache.turbine.services.velocity.TurbineVelocityService.renderingError(Tur
bineVelocityService.java:392)
at
org.apache.turbine.services.velocity.TurbineVelocityService.handleRequest(Turb
ineVelocityService.java:252)
at
org.apache.turbine.services.velocity.TurbineVelocity.handleRequest(TurbineVelo
city.java:109)
at
org.apache.turbine.modules.screens.VelocityScreen.buildTemplate(VelocityScreen
.java:169)
at
org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.java:
130)
at org.apache.turbine.modules.Screen.build(Screen.java:99)
at org.apache.turbine.modules.ScreenLoader.eval(ScreenLoader.java:129)
at
org.apache.turbine.modules.layouts.VelocityOnlyLayout.doBuild(VelocityOnlyLayo
ut.java:98)
at org.apache.turbine.modules.Layout.build(Layout.java:91)
at org.apache.turbine.modules.LayoutLoader.exec(LayoutLoader.java:123)
at org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:166)
at org.apache.turbine.modules.Page.build(Page.java:90)
at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:123)
----- Original Message -----
From: "Santiago Gala" <sg...@hisitech.com>
> Better than this, (I got it), I'm committing a change to the
> CastorPsmlManagerService.
>
> The problem was funny: "/WEB-INF/psml" is *not* absolute under Windows
> (as per java specification, an absolute path in Windows needs the drive
> letter), but it *is* absolute under Unix, so the test:
>
> if( !rootDir.isAbsolute()) was giving different results in both platforms.
> I have chaged it to if( !rootDir.exists() ) so that now, if the root
> does not exist, is taken as context-relative, else it is created.
>
> I'll be commiting right now. It can take a while, as I'm using GPRS + my
> mobile phone from my parent's house in the beach, and the connection is
> flaky.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: actual cvs source not running?
Posted by Santiago Gala <sg...@hisitech.com>.
Raphaël Luta wrote:
> Michael Steindl wrote:
>
>> hi there,
>>
>> having a tremendous problem with the actual cvs files:
>>
>> after building the jetspeed.war I'm receiving the following stack-trace:
>>
>> any idear??
>>
>> =====================================================>
>>
>> Horrible Exception: java.lang.ClassCastException: java.lang.String
>> at
>
>
>
> I've setup a Solaris test box in order to reproduce this bug and it seems
> like there's a weird behavior difference in the Turbine API between Unix
> and Windows:
>
> The cast excpetion comes from the
> getProfile() method is DefaultJetspeedRunData
>
> getProfile()
> {
> return (Profile)rundata.getUser().getTemp("profile");
> }
>
> On Windows, this method returns null when the profile property is not
> set,
> on Unix, it looks like it returns an empty string instead of null for
> some
> reasons.
> I've not yet had the time to investigate more thoroughly and I'd
> appreciate
> if anybody with some time on his hand could track the precise bug.
>
> As an interim fix, you can modify the above method to:
>
> public Profile getProfile()
> {
> Profile profile=null;
> try
> {
> profile=(Profile)this.getUser().getTemp("profile");
> }
> catch (ClassCastException e)
> {
> profile=null;
> }
>
> return profile;
> }
>
> This will get you to the next error but does not solve everything.
Better than this, (I got it), I'm committing a change to the
CastorPsmlManagerService.
The problem was funny: "/WEB-INF/psml" is *not* absolute under Windows
(as per java specification, an absolute path in Windows needs the drive
letter), but it *is* absolute under Unix, so the test:
if( !rootDir.isAbsolute()) was giving different results in both platforms.
I have chaged it to if( !rootDir.exists() ) so that now, if the root
does not exist, is taken as context-relative, else it is created.
I'll be commiting right now. It can take a while, as I'm using GPRS + my
mobile phone from my parent's house in the beach, and the connection is
flaky.
>
> --
> Raphael Luta - raphael.luta@networks.groupvu.com
> Vivendi Universal Networks - Paris
>
>
> ---------------------------------------------------------------------
> 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
Re: actual cvs source not running?
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
Michael Steindl wrote:
> hi there,
>
> having a tremendous problem with the actual cvs files:
>
> after building the jetspeed.war I'm receiving the following stack-trace:
>
> any idear??
>
> =====================================================>
>
> Horrible Exception: java.lang.ClassCastException: java.lang.String
> at
I've setup a Solaris test box in order to reproduce this bug and it seems
like there's a weird behavior difference in the Turbine API between Unix
and Windows:
The cast excpetion comes from the
getProfile() method is DefaultJetspeedRunData
getProfile()
{
return (Profile)rundata.getUser().getTemp("profile");
}
On Windows, this method returns null when the profile property is not set,
on Unix, it looks like it returns an empty string instead of null for some
reasons.
I've not yet had the time to investigate more thoroughly and I'd appreciate
if anybody with some time on his hand could track the precise bug.
As an interim fix, you can modify the above method to:
public Profile getProfile()
{
Profile profile=null;
try
{
profile=(Profile)this.getUser().getTemp("profile");
}
catch (ClassCastException e)
{
profile=null;
}
return profile;
}
This will get you to the next error but does not solve everything.
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
actual cvs source not running?
Posted by Michael Steindl <Mi...@SERprocess.com>.
hi there,
having a tremendous problem with the actual cvs files:
after building the jetspeed.war I'm receiving the following stack-trace:
any idear??
=====================================================>
Horrible Exception: java.lang.ClassCastException: java.lang.String
at
org.apache.jetspeed.services.rundata.DefaultJetspeedRunData.getProfile(Defau
ltJetspeedRunData.java:237)
at
org.apache.jetspeed.modules.actions.JetspeedSessionValidator.doPerform(Jetsp
eedSessionValidator.java:127)
at org.apache.turbine.modules.Action.perform(Action.java:87)
at org.apache.turbine.modules.ActionLoader.exec(ActionLoader.java:122)
at org.apache.turbine.Turbine.doGet(Turbine.java:405)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
java:566)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch
er.java:355)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher
.java:292)
at
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:398)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:58)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:200)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:453)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:254)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:194)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:255)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:225)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2252)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:163)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
875)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:952)
at java.lang.Thread.run(Thread.java:484)
====================================================
cheers,
michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: Not. (was: Re: [LONG] The future of Jetspeed... is with Reptile)
Posted by Dirk Hamstra <di...@iona.com>.
<snip>
>"Live free or die"
>
>Sorry... I value my freedom. After all, I live in America, land of the
free,
>home of the brave :)
>
And of the historically challenged - as a proud resident of the last true
Yankee state it is appalling to see the state motto being raped. The
complete phrase by Gen. John Stark is: "Live free or die, for death is not
the worst of evil". After more clutter and gibberish from the burtonator I
too believe that death can be a pretty good option.
-Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Not. (was: Re: [LONG] The future of Jetspeed... is with Reptile)
Posted by burtonator <bu...@relativity.yi.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jon Stevens <jo...@latchkey.com> writes:
<snip>
> > Don't you think this is illogical? It doesn't matter where you innovate just
> > that it is done in an open manner.
>
> An open manner would have been joining this group (not that I'm sure they
> would even want you back) and participating in a group development.
> Especially since this group is already covering what you intend to cover.
Again... back to my revolutionary idea set. We are introducing too many ideas
and these would never make it though in a committee.
<snip>
> > Again... Doesn't matter what the ASF thinks. It matters what the FSF (and
> > Stallman) thinks.
>
> Bullshit.
Jon... I want this to be a professional discussion. Please watch your tone.
Inviting conflict does not contribute to a productive discussion.
> The ASF is a legal foundation and can make decisions for its own
> code. If the ASF says that the licenses are compatible, then it is up to the
> FSF to sue the ASF. Do you really think that Stallman is that stupid?
This not my point. If the FSF thinks that the licenses are incompatible it will
not use our code, invent their own projects to compete with ours, etc. This is
the situation I want to avoid, not a lawsuit.
I support both the FSF *and* ASF and both of their goals.
<snip>
> If you have a single unrestrictive OPEN (not FREE)
"Live free or die"
Sorry... I value my freedom. After all, I live in America, land of the free,
home of the brave :)
> license on the software,
> then you don't need to dual license things. Period.
(again... putting on my FSF hat) The problem with the BSD is that it allows
paracitism (not trying to insult anyone... this is from game theory). The GPL
protect the original authors freedom.
(putting on the ASF hat) The only problem with the GPL is that it does limit
individuals/corporations in some circumstances when they want to bundle their
code with proprietary code. In some situations this can actually be more
productive than the copyleft policy.
> >>> 3. I have not had time to work within the ASF because I am spending all my
> >>> time
> >>> working on OpenPrivacy. Hopefully this will change soon.
> >>
> >> Lame excuse.
> >
> > yeah... right. Spending 15 hours a day working on OpenPrivacy stuff certainly
> > allows me plenty fo time to work within the ASF.
> > <snip>
>
>
> If you had used Turbine as your framework, then that would have counted as
> part of your 15 hours a day. HELLO?
As it sits today, Reptile has no need for any code within Turbine. The only
layer we will need in the future is something like Torque. At that point I have
no problem contributing fixes/patches/contributions to Turbine.
I hope this clarifies my position a little better.
> I am working on an Issue Tracking system
> in another project on another server (scarab.tigris.org) and I'm using
> Turbine as the basis for it. Somehow I have time during my 15 hours a day to
> work on ASF stuff.
Good for you.
> > Not by my definition. I don't see Ant, Velocity etc as being anything other
> > than a revolution which is 6 months out. These are also tools which impact a
> > very small percentage of the population.
>
> What the hell are you talking about?
>
> Ant is one of the most widely used Java build systems around today. Nearly
> every project (including your own) uses it.
>
> Tomcat gets 100,000k downloads a MONTH!
There are 6 billion people living on this planet? How many of them are Java
developers? 100,000k people is a small number within this population.
I didn't mean to imply that Jakarta isn't important within the Java community.
> > The work we are doing under OpenPrivacy is at least on a 10 year timespan and
> > should affect the entire population of the Internet. ... THAT is a
> > revolution.
>
> Dude, I haven't seen you even get close to finishing a single project yet. I
> haven't even seen you be stable anywhere yet.
You lack my viewpoint. All I care is getting the right feature set to the right
people. If this happens in Jetspeed, Reptile, or whatever it doesn't matter.
As long as it happens.
I believe Reptile brings me much closer to this point. It is the first
technology which we belive can act as a "Primary Agent" in the OpenPrivacy
framework.
> My confidence that you will be working on OP.org for the next 10 years is
> currently at -10000000000.
Can't wait to prove you wrong.
> > Yeah... you are right. What was I thinking. The work I did on Jetspeed was
> > terrible and everyone should stop using/working on it.
>
> Yup.
OK everyone... Jon thinks that the Jetspeed project is terrible and everyone
should stop working on it.
> > Oh wait... don't think that will happen because a lot of people like Jetspeed
> > and want to see it move forward.
>
> A large portion of the code that you did on Jetspeed has long since been
> replaced.
It has been one year! I would expect no less!
> > I hope the Jetspeed team continues and succeeds with all their goals. The
> > only differences WRT Reptile/Jetspeed are that Reptile has a broader set of
> > goals (IMO) and we just have an architecture philosophy difference.
>
> Good luck yourself. Maybe this time you will actually finish something within
> the next 10 years...
I am not going to dignify this statement with a reply.
... and if you choose to reply to this email, please do so in a professional
manner... or don't do so at all.
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
The worse thing in life is to fall short!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE7UKMGAwM6xb2dfE0RAn6dAKCaGmVNMO2TsncetVJ3b9NEqSfsgACgrVcy
ClMDFafT/0gshAfg4x/C6xY=
=y/t5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Not. (was: Re: [LONG] The future of Jetspeed... is with
Reptile)
Posted by Jon Stevens <jo...@latchkey.com>.
on 7/12/01 6:08 PM, "burtonator" <bu...@relativity.yi.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jon Stevens <jo...@latchkey.com> writes:
>
>> on 7/11/01 5:39 PM, "burtonator" <bu...@relativity.yi.org> wrote:
>>
>>> For starters... don't put words in my mouth. Did I say that Jetspeed sucks?
>>> No. I was very careful not to even *remotely* give that impression.
>>
>> "I do not believe this is the future of this technology."
>
> Ah yes.. This carefully worded sentence explains your confusion.
>
>>> I want you to think of this. If I proposed an alternative architecture and
>>> called it Jetspeed 2.0 would your reaction have been so extreme? I don't
>>> think so.
>>
>> Correct. Why? Because it would have you attempting to be a part of this
>> project and not some concoction that you came up with yourself.
>
> Don't you think this is illogical? It doesn't matter where you innovate just
> that it is done in an open manner.
An open manner would have been joining this group (not that I'm sure they
would even want you back) and participating in a group development.
Especially since this group is already covering what you intend to cover.
>>> 1. Turbine is not dual licensed and is not available under the GPL. Huge
>>> restriction to my freedoms. IE I can't use it when I put on my GPL hat.
>>
>> Bullshit. I already told you that the ASF's view is that the two licenses
>> are compatible.
>
> Again... Doesn't matter what the ASF thinks. It matters what the FSF (and
> Stallman) thinks.
Bullshit. The ASF is a legal foundation and can make decisions for its own
code. If the ASF says that the licenses are compatible, then it is up to the
FSF to sue the ASF. Do you really think that Stallman is that stupid?
> I think you miss the point:
>
> - - say you are right. What happens? Nothing. You get to use the BSD
>
> - - say I am right. What happpens? Both licenses can be used by both camps
> and everyone is happy.
> <snip>
Woah Kevin, you didn't even read what you wrote.
If you have a single unrestrictive OPEN (not FREE) license on the software,
then you don't need to dual license things. Period.
>>> 3. I have not had time to work within the ASF because I am spending all my
>>> time
>>> working on OpenPrivacy. Hopefully this will change soon.
>>
>> Lame excuse.
>
> yeah... right. Spending 15 hours a day working on OpenPrivacy stuff certainly
> allows me plenty fo time to work within the ASF.
> <snip>
Bullshit.
If you had used Turbine as your framework, then that would have counted as
part of your 15 hours a day. HELLO? I am working on an Issue Tracking system
in another project on another server (scarab.tigris.org) and I'm using
Turbine as the basis for it. Somehow I have time during my 15 hours a day to
work on ASF stuff.
> Not by my definition. I don't see Ant, Velocity etc as being anything other
> than a revolution which is 6 months out. These are also tools which impact a
> very small percentage of the population.
What the hell are you talking about?
Ant is one of the most widely used Java build systems around today. Nearly
every project (including your own) uses it.
Tomcat gets 100,000k downloads a MONTH!
> The work we are doing under OpenPrivacy is at least on a 10 year timespan and
> should affect the entire population of the Internet. ... THAT is a
> revolution.
Dude, I haven't seen you even get close to finishing a single project yet. I
haven't even seen you be stable anywhere yet.
My confidence that you will be working on OP.org for the next 10 years is
currently at -10000000000.
> Yeah... you are right. What was I thinking. The work I did on Jetspeed was
> terrible and everyone should stop using/working on it.
Yup.
> Oh wait... don't think that will happen because a lot of people like Jetspeed
> and want to see it move forward.
A large portion of the code that you did on Jetspeed has long since been
replaced.
> I hope the Jetspeed team continues and succeeds with all their goals. The
> only differences WRT Reptile/Jetspeed are that Reptile has a broader set of
> goals (IMO) and we just have an architecture philosophy difference.
Good luck yourself. Maybe this time you will actually finish something
within the next 10 years...
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Not. (was: Re: [LONG] The future of Jetspeed... is with Reptile)
Posted by burtonator <bu...@relativity.yi.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jon Stevens <jo...@latchkey.com> writes:
> on 7/11/01 5:39 PM, "burtonator" <bu...@relativity.yi.org> wrote:
>
> > For starters... don't put words in my mouth. Did I say that Jetspeed sucks?
> > No. I was very careful not to even *remotely* give that impression.
>
> "I do not believe this is the future of this technology."
Ah yes.. This carefully worded sentence explains your confusion.
> > I want you to think of this. If I proposed an alternative architecture and
> > called it Jetspeed 2.0 would your reaction have been so extreme? I don't
> > think so.
>
> Correct. Why? Because it would have you attempting to be a part of this
> project and not some concoction that you came up with yourself.
Don't you think this is illogical? It doesn't matter where you innovate just
that it is done in an open manner.
> > 1. Turbine is not dual licensed and is not available under the GPL. Huge
> > restriction to my freedoms. IE I can't use it when I put on my GPL hat.
>
> Bullshit. I already told you that the ASF's view is that the two licenses
> are compatible.
Again... Doesn't matter what the ASF thinks. It matters what the FSF (and
Stallman) thinks.
I think you miss the point:
- - say you are right. What happens? Nothing. You get to use the BSD
- - say I am right. What happpens? Both licenses can be used by both camps and
everyone is happy.
<snip>
> > 3. I have not had time to work within the ASF because I am spending all my
> > time
> > working on OpenPrivacy. Hopefully this will change soon.
>
> Lame excuse.
yeah... right. Spending 15 hours a day working on OpenPrivacy stuff certainly
allows me plenty fo time to work within the ASF.
<snip>
> >> You left a huge mess behind yourself and now you come back expecting or even
> >> suggesting that people jump ship and follow you? You just confirmed my
> >> suspicions that you are nuts. :-)
> >
> > There are number of ways one can categorize another's personality. One is as
> > a
> > revolutionary and yet another is as an evolutionary.
> >
> > I fall into the former category. It is what I am good at. OpenPrivacy
> > technologies are revolutionary and if you have an evolutionary personality I
> > don't expect you to understand/appreciate them.
>
> AHAHAHAHAHAHAHAHAHAHAHAHAH
Very mature response.
> > The ASF *thrives* as an evolutionary model. Anyone who acts as a
> > revolutionary within the ASF is quickly crushed under opposition. Reptile
> > will start to make sense soon but I expect you to still take a stuborn stance.
>
> Bullshit.
>
> Velocity is a revolution. Ant is a revolution. Jserv was a revolution.
> Catalina is a revolution.
Not by my definition. I don't see Ant, Velocity etc as being anything other
than a revolution which is 6 months out. These are also tools which impact a
very small percentage of the population.
The work we are doing under OpenPrivacy is at least on a 10 year timespan and
should affect the entire population of the Internet. ... THAT is a revolution.
> > I think that one of the *best* features of the Open Source model is that
> > revolutionaries and evolutionaries can work together. Clearly Jetspeed has
> > been in the evolutionary process for a while now.
>
> Jetspeed has been stuck trying to clean up the mess you left behind.
Yeah... you are right. What was I thinking. The work I did on Jetspeed was
terrible and everyone should stop using/working on it. Oh wait... don't think
that will happen because a lot of people like Jetspeed and want to see it move
forward.
I hope the Jetspeed team continues and succeeds with all their goals. The only
differences WRT Reptile/Jetspeed are that Reptile has a broader set of goals
(IMO) and we just have an architecture philosophy difference.
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
$live{free} || die "";
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE7TkobAwM6xb2dfE0RAiWbAKDLdK6x+Sd9O5QBpYKoW6HiejHzwwCgwEJ1
Ekxkajh9tgHhXol1oq65zNo=
=Ai83
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Not. (was: Re: [LONG] The future of Jetspeed... is with
Reptile)
Posted by Jon Stevens <jo...@latchkey.com>.
on 7/11/01 5:39 PM, "burtonator" <bu...@relativity.yi.org> wrote:
> For starters... don't put words in my mouth. Did I say that Jetspeed sucks?
> No. I was very careful not to even *remotely* give that impression.
"I do not believe this is the future of this technology."
> I want you to think of this. If I proposed an alternative architecture and
> called it Jetspeed 2.0 would your reaction have been so extreme? I don't
> think so.
Correct. Why? Because it would have you attempting to be a part of this
project and not some concoction that you came up with yourself.
> 1. Turbine is not dual licensed and is not available under the GPL. Huge
> restriction to my freedoms. IE I can't use it when I put on my GPL hat.
Bullshit. I already told you that the ASF's view is that the two licenses
are compatible.
> 2. The main objections I have to Turbine is that it is WAY TOO BIG. When some
> of this stuff moves to the Commons this will be negated.
Bullshit. I already told you that we are doing that as well as making
Turbine smaller. We just released 2.2a2. GO LOOK AT IT.
> 3. I have not had time to work within the ASF because I am spending all my
> time
> working on OpenPrivacy. Hopefully this will change soon.
Lame excuse.
> 4. I don't have the time to fix EVERY project. I spend around 15 hours a day
> hacking on code... where will I get the time to work on the Turbine project?
I'm not asking you to do that. I'm asking you to look at Turbine where it is
today. Even when you did spend time here, you didn't even bother to fully
grasp it. It shows in your badly done Jetspeed code.
>> #2. Tell me the truth, when was the last time you really took a good look at
>> Turbine?
>
> ... around 30 days ago.
Too long ago.
>> Have you see what is going on in the HEAD? Somehow,
>
> yes...
30 days ago.
>> I doubt it.
>
> because I don't checkout others code and read it???
How about reading the mailing list archives?
> I was trying to ship Jetspeed on a *real* timetable. Something which the
> Turbine project didn't think was worth their time. I didn't have time to
> rewrite Jetspeed ever day because the Turbine API changed.
You didn't even understand the API to begin with.
>> You left a huge mess behind yourself and now you come back expecting or even
>> suggesting that people jump ship and follow you? You just confirmed my
>> suspicions that you are nuts. :-)
>
> There are number of ways one can categorize another's personality. One is as
> a
> revolutionary and yet another is as an evolutionary.
>
> I fall into the former category. It is what I am good at. OpenPrivacy
> technologies are revolutionary and if you have an evolutionary personality I
> don't expect you to understand/appreciate them.
AHAHAHAHAHAHAHAHAHAHAHAHAH
> The ASF *thrives* as an evolutionary model. Anyone who acts as a
> revolutionary within the ASF is quickly crushed under opposition. Reptile
> will start to make sense soon but I expect you to still take a stuborn stance.
Bullshit.
Velocity is a revolution. Ant is a revolution. Jserv was a revolution.
Catalina is a revolution.
> I think that one of the *best* features of the Open Source model is that
> revolutionaries and evolutionaries can work together. Clearly Jetspeed has
> been in the evolutionary process for a while now.
Jetspeed has been stuck trying to clean up the mess you left behind.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Not. (was: Re: [LONG] The future of Jetspeed... is with Reptile)
Posted by burtonator <bu...@relativity.yi.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jon Stevens <jo...@latchkey.com> writes:
> on 7/11/01 3:11 PM, "burtonator" <bu...@relativity.yi.org> wrote:
>
> > ... not trying to make any friends. I am trying to further science... which I
> > think is more important than making friends. I also apologized ahead of time
> > if
> > you remember.
> >
> > ... please try to keep an open mind with this stuff.
>
> With what stuff? With you popping up from nowhere and saying that Jetspeed
> sucks and is the wrong direction? I don't think so.
For starters... don't put words in my mouth. Did I say that Jetspeed sucks?
No. I was very careful not to even *remotely* give that impression.
What I want you to be open minded about is the technical merits of Reptile.
I am a firm believer in Natural Selection and I believe that the best man will
win..
I want you to think of this. If I proposed an alternative architecture and
called it Jetspeed 2.0 would your reaction have been so extreme? I don't think
so.
<snip>
> I'm not concerned with flexibility because the BSD is flexible enough for me
> (and more flexible than the GPL) and the ASF carries the position that the
> ASF License is indeed compatible with the GPL. But, I'm not going to get
> into a licensing debate with you as I have done it before and it isn't worth
> wasting my time.
fine... and you get to use Reptile under the BSD license... so no problem.
> > I expect you have examples to back that insult up??? :) It is still early
> > code. I need to put another pass over Talon/Sierra though.
>
> Glancing at the framework stuff leaves me wondering why you are creating yet
> another framework once again.
I assume you are referring to Talon? Talon has two major advantages. It is
SIMPLE!!! ... and it will also include Reputation based component selection
which has never been done anywhere before.
> Here we are about two years later and you are back at the same point.
I don't view it this way and in fact I think that this stuff is significantly
more advanced than the stuff I was using two years ago.
> > I think it is naive for you to think I have no good things to say about
> > Turbine. I have a LOT of good things to say about Turbine. However, just like
> > everything ever invented there are some BAD things in it though.
>
> #1. You could have stepped up to modify Turbine to make it fit your needs
> instead of re-inventing the wheel yet again. So, your argument is lame.
Sure ... ok... let's analyze this.
1. Turbine is not dual licensed and is not available under the GPL. Huge
restriction to my freedoms. IE I can't use it when I put on my GPL hat.
2. The main objections I have to Turbine is that it is WAY TOO BIG. When some
of this stuff moves to the Commons this will be negated.
3. I have not had time to work within the ASF because I am spending all my time
working on OpenPrivacy. Hopefully this will change soon.
4. I don't have the time to fix EVERY project. I spend around 15 hours a day
hacking on code... where will I get the time to work on the Turbine project?
> #2. Tell me the truth, when was the last time you really took a good look at
> Turbine?
... around 30 days ago.
> Have you see what is going on in the HEAD? Somehow,
yes...
> I doubt it.
because I don't checkout others code and read it???
> Even when you were working with Turbine, you made little effort to actually
> understand it and implement Jetspeed correctly within the Turbine model.
I was trying to ship Jetspeed on a *real* timetable. Something which the
Turbine project didn't think was worth their time. I didn't have time to
rewrite Jetspeed ever day because the Turbine API changed.
> You left a huge mess behind yourself and now you come back expecting or even
> suggesting that people jump ship and follow you? You just confirmed my
> suspicions that you are nuts. :-)
There are number of ways one can categorize another's personality. One is as a
revolutionary and yet another is as an evolutionary.
I fall into the former category. It is what I am good at. OpenPrivacy
technologies are revolutionary and if you have an evolutionary personality I
don't expect you to understand/appreciate them.
The ASF *thrives* as an evolutionary model. Anyone who acts as a revolutionary
within the ASF is quickly crushed under opposition. Reptile will start to make
sense soon but I expect you to still take a stuborn stance.
I think that one of the *best* features of the Open Source model is that
revolutionaries and evolutionaries can work together. Clearly Jetspeed has been
in the evolutionary process for a while now.
<snip>
> > I don't consider that I "bashed" Turbine and I think you are taking it too
> > seriously. I merely think it is non-ideal.
>
> That's good, because I think pretty much everything that I have seen you do
> as "non-ideal." :-)
>
> Personally, I like people who stick around a project for the long haul and
> work to improve things over people who come and go randomly and leave
> unfinished messes behind.
See my above comment.
> I applaud the Jetspeed developers for picking up that mess and at least
> attempting to shape it into something worthwhile.
... as do I.
> Good luck with your cathedral Kevin.
Good luck with your bizarre Jon. (pun intended).
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
In the end, only kindness matters.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE7TPGrAwM6xb2dfE0RAiaOAKCl0mKuaKtZpYqyPl32WUI0WuJ/MwCfagcJ
P8PW43/gsyivupqs6hpbFz4=
=n21O
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Not. (was: Re: [LONG] The future of Jetspeed... is with
Reptile)
Posted by Jon Stevens <jo...@latchkey.com>.
on 7/11/01 3:11 PM, "burtonator" <bu...@relativity.yi.org> wrote:
> ... not trying to make any friends. I am trying to further science... which I
> think is more important than making friends. I also apologized ahead of time
> if
> you remember.
>
> ... please try to keep an open mind with this stuff.
With what stuff? With you popping up from nowhere and saying that Jetspeed
sucks and is the wrong direction? I don't think so.
> It is going to be dual licensed BSD and GPL.
>
> I just stamped the GPL by default. All of our stuff will be dual licensed.
> This will be fixed before 0.0.1 is released.
>
> BTW... I believe that this licensing model will be MORE flexible than the BSD
> model :)
I'm not concerned with flexibility because the BSD is flexible enough for me
(and more flexible than the GPL) and the ASF carries the position that the
ASF License is indeed compatible with the GPL. But, I'm not going to get
into a licensing debate with you as I have done it before and it isn't worth
wasting my time.
> I expect you have examples to back that insult up??? :) It is still early
> code. I need to put another pass over Talon/Sierra though.
Sorry, I'm not going to help you with your code because I already have
enough on my plate. Glancing at the framework stuff leaves me wondering why
you are creating yet another framework once again. Here we are about two
years later and you are back at the same point. I don't get you sometimes.
>> and Turbine's design are even funnier.
>
> ... because I borrowed some good ideas from Turbine.
>
> "If I have seen further than others, it is because I have stood on the
> shoulders
> of giants."
>
> - Albert Einstein
I doubt that Albert called the other people's works that he was duplicating
a "hindrance."
> I think it is naive for you to think I have no good things to say about
> Turbine. I have a LOT of good things to say about Turbine. However, just like
> everything ever invented there are some BAD things in it though.
#1. You could have stepped up to modify Turbine to make it fit your needs
instead of re-inventing the wheel yet again. So, your argument is lame.
#2. Tell me the truth, when was the last time you really took a good look at
Turbine? Have you see what is going on in the HEAD? Somehow, I doubt it.
Even when you were working with Turbine, you made little effort to actually
understand it and implement Jetspeed correctly within the Turbine model. You
left a huge mess behind yourself and now you come back expecting or even
suggesting that people jump ship and follow you? You just confirmed my
suspicions that you are nuts. :-)
> Failure to admit this would be foolish.
2.1 is a mess. 2.2/3.0 is very nice. Jason van Zyl is leading the effort and
I have great confidence in his work and his design skills. They are much
better than mine and he has the time to devote to it.
> I don't consider that I "bashed" Turbine and I think you are taking it too
> seriously. I merely think it is non-ideal.
That's good, because I think pretty much everything that I have seen you do
as "non-ideal." :-)
Personally, I like people who stick around a project for the long haul and
work to improve things over people who come and go randomly and leave
unfinished messes behind.
I applaud the Jetspeed developers for picking up that mess and at least
attempting to shape it into something worthwhile.
Good luck with your cathedral Kevin.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Not. (was: Re: [LONG] The future of Jetspeed... is with Reptile)
Posted by burtonator <bu...@relativity.yi.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jon Stevens <jo...@latchkey.com> writes:
> Hey Kevin,
>
> Nice advertisement for your latest and greatest "innovation".
>
> I seriously doubt that popping up from nowhere and sending an email telling
> everyone here that what they are doing is wrong is going to win many
> friends.
... not trying to make any friends. I am trying to further science... which I
think is more important than making friends. I also apologized ahead of time if
you remember.
... please try to keep an open mind with this stuff.
> I'm not impressed...especially not by the GPL license you have on all of
> your software that you conveniently forgot to mention.
It is going to be dual licensed BSD and GPL.
I just stamped the GPL by default. All of our stuff will be dual licensed.
This will be fixed before 0.0.1 is released.
BTW... I believe that this licensing model will be MORE flexible than the BSD
model :)
> The great similarities with the design of your framework code (which looks
> like overcooked spaghetti noodles to me)
I expect you have examples to back that insult up??? :) It is still early
code. I need to put another pass over Talon/Sierra though.
> and Turbine's design are even funnier.
... because I borrowed some good ideas from Turbine.
"If I have seen further than others, it is because I have stood on the shoulders
of giants."
- Albert Einstein
> Gee, I bet it is easy to bash Turbine and then borrow all of the good ideas
> from it.
I think it is naive for you to think I have no good things to say about Turbine.
I have a LOT of good things to say about Turbine. However, just like everything
ever invented there are some BAD things in it though. Failure to admit this
would be foolish.
I don't consider that I "bashed" Turbine and I think you are taking it too
seriously. I merely think it is non-ideal.
> Good luck with your project.
<snip>
Thanks.
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
They have the guns, money, and press but we have the technology!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE7TM8WAwM6xb2dfE0RAgDmAJ45McAZUqCQXYR61/UG8ioANGTyZACeN02I
u+/s4HnS0Zsh6uA99opRVsw=
=Jo5X
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Not. (was: Re: [LONG] The future of Jetspeed... is with Reptile)
Posted by Jon Stevens <jo...@latchkey.com>.
Hey Kevin,
Nice advertisement for your latest and greatest "innovation".
I seriously doubt that popping up from nowhere and sending an email telling
everyone here that what they are doing is wrong is going to win many
friends.
I'm not impressed...especially not by the GPL license you have on all of
your software that you conveniently forgot to mention.
The great similarities with the design of your framework code (which looks
like overcooked spaghetti noodles to me) and Turbine's design are even
funnier. Gee, I bet it is easy to bash Turbine and then borrow all of the
good ideas from it.
Good luck with your project.
:-)
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
JetSpeed 2
Posted by 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
RE: [LONG] The future of Jetspeed... is with Reptile
Posted by David Sean Taylor <da...@bluesunrise.com>.
>
> 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.
>
> 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!
>
>
>
> -----BEGIN PGP SIGNATURE-----
> 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
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> 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