Jon Stevens wrote:
> on 1/29/01 11:40 AM, "David Sean Taylor" <[EMAIL PROTECTED]>
> wrote:
(...)
> > I have also brought up the fact on this mailing list that invocations of the
> > Persistence Service required multiple 'new' persistence services per
> > request.
> > So this means that since the lifetime of the service object is only for one
> > request, its then safe to 'cache' the RunData, since the service object will
> > be gone after the request.
>
> Ok. I was just checking.
>
This should be said in comments in the code. We are taking the risk that
somebody uses this code as a pattern for further development or new
services, without respecting the implicit "contract" there. I have
suffered enough with programs, either mine of coming from other people,
that did not properly document hacks, temporary solutions or
workarounds, hidden contracts, ...
It is important that we remember every day that the code base is our
main communication mean, even more than this list.
> > This is counter to how I believe services should work, again I've discussed
> > this on the list.
>
> Then maybe implement it differently?
>
> > In defense of the authors, I believe that the PersistenceService was written
> > as a 'temporary solution', since the underlying classes used by it i.e. the
> > PortletSet and PSMLManager are due for some major overhauls. In that spirit,
> > I left the service as is since it works for now.
> >
> > Im all for rewriting the Persistence Service to be a Turbine Service. But
> > when I suggested that, it was argued that we are considering our own service
> > model for the 'Portal API' that isn't dependent on anything else. The
> > committers to this service will be able to describe this more, but they are
> > in Europe so it probably won't be til tomorrow.
>
> Ok, I'm *strongly* -1 on any more Services frameworks being built.
I think the comments in the list were oriented to have a specification
that was completely independent of implementation issues. We do not plan
to write yet another services framework. At least I hope so :)
>
> Please look at the BaseService class in Turbine. It is a very clean
> framework for building Services. One could easily build a PortletService on
> top of BaseService....instead of having it built on top of TurbineServices.
>
> If you look at the BaseService, it does nothing more than import java.util.
> There is zero dependencies on any of the rest of the system.
I imagine that we will converge eventually towards Avalon. I expect this
to happen, so that we can merge freely turbine services, cocoon
services, etc. I have read that you are considering this for turbine
once it is released, and I think this is a move in the right direction
for everybody, as we will have better use of our developer base if
services are maintained for several projects together.
>
> > Damn, now I suppose that everytime you see my name, you will think "iFoo",
> > or even worse, the "iFoo Propagator".
> > Where's there a corner I can hide in....
>
> Oh, don't say immature things when someone simply asks why things are being
> done the way that things are being done. This project has a long history of
> not doing things properly...work to fix it, not to make it worse.
>
I did not like the code, either. I had not read it until you pointed the
fact that it was there. I cannot understand the purpose, and I'm
supposed to be good at reverse engineering. But David, again, just
adapted it.
I think that the original authors can say if they feel it is right or
not, and work together to get code that is easier to understand and
better commented. In this way we will be working to have a better code
base.
> thanks,
>
> -jon
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
