That is a very good point Chuck, not only does Pluto 1.1 have an active development group the architecture makes adding support for features/hooks you need very easy.

-Eric

Charles Severance wrote:
Let me amplify (a bit) on something Eric said...

On Mar 3, 2007, at 9:30 AM, Eric Dalquist wrote:

Not sure how much help that is going to be but I will also say that the effort is worth it. We ended up being able to remove a significant amount of code by upgrading and simplify much of our framework.

Sakai uses Pluto 1.1 in a much simpler fashion than uPortal 3.0 because Sakai is using 168 as a "plugin" and uPortal 3 is a real portal. So uPortal's requirements were richer than Sakai's requirements.

One thing that happened (you can see the trail of this in JIRA) is that when uPortal 3.0 needed a feature (or had to build that feature to compensate for a lack in Pluto 1.0) we added the feature to Pluto 1.1 *not* to uPortal and then have uPortal use the new feature in Pluto. As you can see from the JIRA and the commit log - this was a pretty agile process :)

This way we all get this functionality and it works the same way for all portals rather than separately maintaining independent code.

You also saw this when Eric moved his war processing into Pluto rather than keeping it in uPortal.

So when Eric says "we removed code" - it was very much on purpose and he made decisions to improve Pluto 1.1 instead of workaround limitations by adding code to uPortal 3.0.

/Chuck

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to