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 ta...@apache.org on 2003/12/30 07:50:33 UTC
cvs commit: jakarta-jetspeed-2/docs PortletAPI-todo.txt TODO-2.0a1.txt
taylor 2003/12/29 22:50:33
Modified: docs PortletAPI-todo.txt TODO-2.0a1.txt
Log:
updating todo stuff (scary)
Revision Changes Path
1.3 +0 -11 jakarta-jetspeed-2/docs/PortletAPI-todo.txt
Index: PortletAPI-todo.txt
===================================================================
RCS file: /home/cvs/jakarta-jetspeed-2/docs/PortletAPI-todo.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- PortletAPI-todo.txt 29 Jul 2003 21:44:45 -0000 1.2
+++ PortletAPI-todo.txt 30 Dec 2003 06:50:33 -0000 1.3
@@ -11,16 +11,5 @@
so Im not sure how Pluto accesses factories before the container is called per thread.
But it seems to work in Pluto. Cant figure this one out yet
-3. org.apache.jetspeed.aggregator.BasicAggregator
- - cleanup, combine with PSML
- - remove simplistic PortletEntity creation
- - find a way to cache PSML and PortletEntity objects in session
-
----------------------------------
-Misc
----------------------------------
-
-1. Old PortletContainer [DONE]
-- remove all code related-to the old container and old request/response impls and wrappers
1.2 +28 -19 jakarta-jetspeed-2/docs/TODO-2.0a1.txt
Index: TODO-2.0a1.txt
===================================================================
RCS file: /home/cvs/jakarta-jetspeed-2/docs/TODO-2.0a1.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TODO-2.0a1.txt 28 Jul 2003 23:47:23 -0000 1.1
+++ TODO-2.0a1.txt 30 Dec 2003 06:50:33 -0000 1.2
@@ -1,22 +1,31 @@
-----------------------------------------------------------------
+-------------------------------------------------------------------------
T O D O L i s t
-----------------------------------------------------------------
-
------------------------------------------------------------------------------------------------------------
-2003-05-22
-
-Think we need to be able to get the portlets out of the registry.
-Still have some problems there with the deploy.
-
-
------------------------------------------------------------------------------------------------------------
-2003-05-23
-
-- Separate Test registry data from Deployed registry data
-- Separate Test PSML from Deployed PSML data
-- Change Application to have APP_ID
-- Deploy tool needs to write Application to Registry
-- PortletConfig to pass to portlet.init().
-
+-------------------------------------------------------------------------
+Here is a list of stuff that you can work on if you find it interesting
+-------------------------------------------------------------------------
+* PAM *
+-------------------------------------------------------------------------
+- refactor PAM maven tasks to simply copy WAR to a deploy directory
+- Move PAM into portal runtime. A directory watcher will pick up new deployments
+ and kickoff the PAM to actually do the deployment.
+ This implies that the portal server must be running to pick up a deployment
+- remove funky code to look in the $HOME directory for the database path (yech)
+
+ASSIGNED:
+
+-------------------------------------------------------------------------
+* Pooling *
+-------------------------------------------------------------------------
+- All Pluto factory objects such as request, response, dispatchers, invokers, contexts need to be pooled
+
+ASSIGNED: DST
+
+-------------------------------------------------------------------------
+* Database *
+-------------------------------------------------------------------------
+- Consider using PA-NAME + PORTLET-NAME as a unique key to find portlets
+ Currently it is, which can't make queries like SELECT NAME FROM PORTLET_DEFINITION run too fast.
+ UNIQUE(APPLICATION_ID, NAME)
+- Rework the way we find the database. Having a property in the $HOME directory isn't going to cut it
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org