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

[David Toshack]

Michael Scharkow wrote:
> 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.

This probably isn't the place to bang on too much about Portal 
definitions, but I have included some urls[1] if you're interested. As 
with most standards, the definitions are a lot more generic than the 
above mentioned frameworks but I hope they also head in this portal 
based direction. I apologise if this presents more questions than answers.

> 
>> 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?


Taking another look at the TYPO3 roadmap[2], JSR-168 compliance must 
have been wishful thinking, "Portal Standard" is the wording used. The 
more I think about it, "Fall 2006", or even 2007 as an approximate 
release date would be grossly over ambitious for JSR-168 compliance 
anyway, sorry about that.

Graffito is a new addition to The Apache Project, loosely speaking its 
like what Content Elements w/ DAM is for TYPO3 (if TYPO3 represented all 
JSR-170 compliant portals).

> 
>> 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?

In this "perfect world", the TYPO3 specific stuff would consist _mainly_ 
of PSML configuration. PSML is basically an XML DTD along with an 
interface to write it to files or a database, which is part of Jetspeed. 
Pretty much what TypoScript is for TYPO3, or what TypoScript _could_ be 
for TYPO3 with the proposed YAML[3], with wishfully, Syck[4] solution.

> 
> Seriously, I find this 'perfect world' perfectly scary because it will 
> lead to infinite specificasionism, tons of glue code (ever bothered 
True Dat!

> 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 

Thats where Apache Bridges[5] come in. Completely integrated PHP 
portlets already exist for Jetspeed.

> 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.

Touche! I can foresee Geronimo[6] (Apache version of J2EE server), 
becoming quite closely integrated with The Apache Web Server in the near 
future though, so this may not be the case for to much longer.

> 
> 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.

You are right on the money there. I have no comeback for this. I would 
imagine Jetspeed will some day be closely integrated with Geronimo, and 
therefore with Apache. A logical transition I would think, unfortunately 
this is only going on in my head at the moment and is not a reality   lol

> 
> 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.

I agree completely Michael. Unless my prediction becomes reality. Which 
I'm sure it won't to the point where its comparative to the simplicity 
of the standard LAMP stack for quite some time, if at all. On the other 
hand, these industry standards should by no means be ignored, even if 
not implemented.

That is my intention, to accentuate the possibility that TYPO3 does not 
have to go it alone. Maybe my original email should have been more 
focused on WSRP[7], and not a specific solution.

> 
> 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.

Not sure about _most_, but I do see your point. The problem with Java 
development is that its very expensive expertise and very time consuming 
work. Much easier to pump out scripts than well structured applications. 
  I do _definitely_ agree with you there. Hey, I've been building PHP 
web apps for the last 10 years, ever since PHP I have done little to no 
Java development, its the standards I'm after, not the language. I'm a 
firm believer in "The right tools for the job".

> 
>> 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.

I agree, starting from scratch would be crazy. You wouldn't do it for 
the badge, you'd do it to have access to all the other JSR-XXX 
advantages[1].

> 
> 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.

Maybe so, but that would defeat the purpose. The purpose is to ad hear 
to a standard for compatibility. I do admit, I'm a bit of a standards freak!

> 
>> 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!

My pleasure Michael, thanks for yours!

Cheers,
David


[1] http://wiki.java.net/bin/view/Portlet/JSR168FAQ
     http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-portlet-p3.html
     http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-portlet2.html
[2] http://typo3.org/development/roadmap
[3] http://www.yaml.org
[4] http://whytheluckystiff.net/syck
[5] http://portals.apache.org/bridges
[6] http://geronimo.apache.org
[7] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp