You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "David H. DeWolf" <dd...@apache.org> on 2006/09/01 06:01:07 UTC

Seperating portal-driver into api and impl

All,

We've had some new interest by different portals wanting to embed pluto. 
  Specifically, I'm helping Sakai embed pluto into their  portal and 
there may be a couple of other open source portals wanting to do the 
same after we have success with Sakai.  This is obviously good news for 
our community.

In order to assist with this, I'd like to separate out the portal-driver 
into an api (interfaces) and an impl project.  I know we've discussed 
not making the portal too feature heavy  (since we're really a project 
about the container), so I wanted to discuss this before I made the 
separation.

IMHO this won't make anything more complex since I won't be adding 
anything additional, it will just create a clean separation so that 
others can more implement robust solutions (such as db driven 
implementations) without having to worry about the impls provided.

I've got the refactoring ready to commit. I'll wait till I hear from a 
few of you before I make the change.


Thanks,


David

Re: Seperating portal-driver into api and impl

Posted by Stefan Hepper <st...@apache.org>.
+1

(I don't think this gets us too far into the portal business)

Stefan

David H. DeWolf wrote:
> All,
>
> We've had some new interest by different portals wanting to embed 
> pluto.  Specifically, I'm helping Sakai embed pluto into their  portal 
> and there may be a couple of other open source portals wanting to do 
> the same after we have success with Sakai.  This is obviously good 
> news for our community.
>
> In order to assist with this, I'd like to separate out the 
> portal-driver into an api (interfaces) and an impl project.  I know 
> we've discussed not making the portal too feature heavy  (since we're 
> really a project about the container), so I wanted to discuss this 
> before I made the separation.
>
> IMHO this won't make anything more complex since I won't be adding 
> anything additional, it will just create a clean separation so that 
> others can more implement robust solutions (such as db driven 
> implementations) without having to worry about the impls provided.
>
> I've got the refactoring ready to commit. I'll wait till I hear from a 
> few of you before I make the change.
>
>
> Thanks,
>
>
> David
>
>



Re: Seperating portal-driver into api and impl

Posted by Elliot Metsger <em...@jhu.edu>.
+1

Sounds like a good thing to do from a code architecture/best practices 
standpoint.

Elliot

David H. DeWolf wrote:
> All,
> 
> We've had some new interest by different portals wanting to embed pluto. 
>  Specifically, I'm helping Sakai embed pluto into their  portal and 
> there may be a couple of other open source portals wanting to do the 
> same after we have success with Sakai.  This is obviously good news for 
> our community.
> 
> In order to assist with this, I'd like to separate out the portal-driver 
> into an api (interfaces) and an impl project.  I know we've discussed 
> not making the portal too feature heavy  (since we're really a project 
> about the container), so I wanted to discuss this before I made the 
> separation.
> 
> IMHO this won't make anything more complex since I won't be adding 
> anything additional, it will just create a clean separation so that 
> others can more implement robust solutions (such as db driven 
> implementations) without having to worry about the impls provided.
> 
> I've got the refactoring ready to commit. I'll wait till I hear from a 
> few of you before I make the change.
> 
> 
> Thanks,
> 
> 
> David

Re: Seperating portal-driver into api and impl

Posted by "David H. DeWolf" <dd...@apache.org>.

CDoremus@hannaford.com wrote:
> 
> +1
> 
> I assume that you will be able to configure implementations in 
> pluto-portal-driver-services-config.xml. Is that correct?
> /Craig
> 
> 

Yes.  If you look at what's been committed I think it's a good example. 
  In fact, this modification encourages more of a dependency injection 
approach and even more things are configured via the IoC container.

David

Re: Seperating portal-driver into api and impl

Posted by CD...@hannaford.com.
+1

I assume that you will be able to configure implementations in 
pluto-portal-driver-services-config.xml. Is that correct?
/Craig




"David H. DeWolf" <dd...@apache.org> 
Sent by: "David H. DeWolf" <dd...@gmail.com>
09/01/2006 12:01 AM
Please respond to
pluto-dev@portals.apache.org


To
pluto-dev@portals.apache.org
cc

Subject
Seperating portal-driver into api and impl






All,

We've had some new interest by different portals wanting to embed pluto. 
  Specifically, I'm helping Sakai embed pluto into their  portal and 
there may be a couple of other open source portals wanting to do the 
same after we have success with Sakai.  This is obviously good news for 
our community.

In order to assist with this, I'd like to separate out the portal-driver 
into an api (interfaces) and an impl project.  I know we've discussed 
not making the portal too feature heavy  (since we're really a project 
about the container), so I wanted to discuss this before I made the 
separation.

IMHO this won't make anything more complex since I won't be adding 
anything additional, it will just create a clean separation so that 
others can more implement robust solutions (such as db driven 
implementations) without having to worry about the impls provided.

I've got the refactoring ready to commit. I'll wait till I hear from a 
few of you before I make the change.


Thanks,


David