[TYPO3-dev] TYPO3 JSR-168/JSR-170 compliance w/ Jetspeed, Graffito and all that comes with it!

[Michael Scharkow]

David Toshack wrote:
> Hi Everyone,
> 
> I came across a post on the wiki[1],
> regarding Rails which sparked some interest in a cross language
> implementation that has been in the back of my mind for quite some time.

Hi David,

> I'm not sure how many of you are familiar with the projects being
> developed at Apache Portals [2], but originally part of the Apache
> Jakarta Project, it has been in existance for ~10 years. Since the word
> "portal" was used to represent a web application, Jetspeed[3] has
> argueably been THE standard in portal frameworks.

I cannot really say anything about that, except that 1) after years of 
experience with TYPO3 and occasional peeks into a lot of other web 
content technologies (ZOPE, Plone, Rails, Django, etc.) I still have not 
understood what exactly a portal (in the JAVA/Apache/Enteprise speak) is 
and does. 2) I can't even gather what jetspeed is or does from their 
website, except that it must be something that uses XML and JAVA and 
runs with (on top of?) Tomcat, or such.

> As TYPO3 5.0 will be leaning towards JSR-168 compliance, and hopefully
> JSR-170 compliance, Jetspeed2 and Graffito would be a great way to
> achive this with a brand spanking new TYPO3 interface. Graffito is a CMS
> Framework[4] currently undergoing incubation at the home of Apache.

I did not know that TYPO3 was seriously targeting those specs. And 
Graffito is exactly how related to jetspeed? What Plone is to ZOPE, or 
what TYPO3 is to PHP, or Rails to Ruby, or Instiki/typo to Rails?

> In this perfect world TYPO3 could use any number of languages or 
> frameworks (including Struts, PHP, Python, Ruby, w/on Rails ... etc) for 
> portlet development, and have access to thousands of portlets available 
> that would simply "plugin", excuse the pun! In effect TYPO3 would 
> basically become a series of PSML (XML based - Portal Structure Markup 
> Language[5]) configurations. These concepts have been put together over 
> the last 10 or so years by the best heads in the business and have 
> turned the fellow heads of developers involved in some huge corporate 
> scale open source projects, like ofbiz[6], WfMOpen[7], IBM's 
> WebSphere[8] and many more.

Okay, I beg your pardon if I'm completely mistaken: You propose to 
completely rewrite TYPO3 in JAVA (or XML for jetspeed, or Graffito), 
only to have it somehow interact with all that JAVA/XML/Enterprise 
stuff? If Graffito already exists, why should one port TYPO3 to JAVA and 
not use Graffito which seems to do the same thing?
And why should we abandon thousands of extensions we have now, that are 
basically plug'n'play, only to interact with some other portlets(?) that 
do the same only that they adhere to spec JSR-xyz?

Seriously, I find this 'perfect world' perfectly scary because it will 
lead to infinite specificasionism, tons of glue code (ever bothered 
glueing PHP to Java?) and no results. I am admittedly not a friend of 
JAVA (or rather the software engineering methods around JAVA), but the 
fact that I need a 70MB jetspeed package, a TOMCAT server and tons of 
PSML to produce a website that has a forum and a guestbook just makes me 
run, away, quickly.

I do tend to think that TYPO3 alone as a framework is already quite 
heavyweight, and I'd rather slim it down with 5.0 than transform our 
beloved 500 lbs gorilla into King Kong.

Also, I don't buy the best-of-industry-heads argument because that's all 
too common when it comes to the "Enterprise" discussion. Saying that 
being able to mess with BEA or Websphere is in this context like the 
usual nobody-ever-got-fired-for-using-Oracle/IBM/Whatever argument: It 
may well be true, but it doesn't help for the goals we have. TYPO3 is 
supposed to be run by indididuals and small business as well as large 
corporate websites, it is supposed to be easy to 
install/configure/extend and run in the standard LAMP stack.

There might be a huge market in JAVA-based portal software, but I don't 
think TYPO3 belongs in there. Moreover, most of the large and successful 
websites *don't* run on JAVA portals: amazon, google, slashdot, younameit.

> I believe The TYPO3 Association is bigger than the software it has
> created, and going by the TYPO3 community's reputation, this approach
> would no doubt become THE standard in portal implementations. But the
> question: Is this the right place for the job? I don't know, it would
> mean a huge leap and learning curve for most core developers with
> knowledge only in PHP.

Again, I don't see why we should start from scratch, lose most of our 
users and developers, only to be able to put a "implements JSR XXX" or a 
"works with Websphere, SAP and .NET" badge on our website.

As for the learning curve: JAVA itself should not be the problem, a lot 
of the devs here have some JAVA background (hi Sven!), but the 
surrounding infrastructure that you mention above is just a huge mass of 
code and specs to read only to re-implement the most basic TYPO3 
features. I guess it would be faster and less painful to rewrite TYPO3 
in OCAML or Smalltalk.

> Ambitous I know. Some of you are probably thinking bbbfffttthhh to Java,
> more like TYPO3 10.0, but it is only software; you could imagine it right?

Sorry, I can't imagine that. But that's probably my fault.

Thanks for the discussion input!

Greetings,
Michael