Forum .LRN Q&A: Re: Request for advice from the OCT

Collapse
6: Re: Request for advice from the OCT (response to 1)
Posted by Ola Hansson on 06/11/04 04:51 PM
There needn't be a problem if we can clarify conceptually how things should be implemented before we do it. Isn't it rather the case that if we implement the capabilities to create sequences in general, there would be no need for implementing corresponding capabilities specific to LORS[m]? As a paralell, we might consider how the generic Categories package lets various other packages have their objects mapped to centrally defined categories. Just a thought ...

There is a problem, however, because Ernie won't clarify the need for a separate SS front-end within LORSm, although we've explained there will be a general one, but instead presents us with an ultimatum and threatens to cowboy in on our SS initiative. We have no problem with going Ernies route (public API, several front-ends) if he could just convince us and the OCT that his approach represents the best practice.

Collapse
7: Re: Request for advice from the OCT (response to 6)
Posted by Jeff Davis on 06/11/04 05:28 PM
As you stated it, I like Ernie's approach better, I think defining a clean API that is well suited to reuse is better software engineering. Take the CMS/CR for example. At the time they were written it was not obvious that the CR would really need to be exposed to anything else, but subsequently the CMS ended up being discarded and now there are a number of other packages which use that API with very few changes.

I think most things (SS included) should be done with a service layer and a presentation layer (with the possibility of creating other vehicles for presentation) and even though you think the whole thing should be server side, I think forcing that decision into the design is a bad one.

If you are saying you don't want to force that decision into the design then I don't see why there is any conflict at all since you are in effect saying you want an ss-service + an ss-presentatio-layer package where Ernie says he want's ss-service + LORSm (== another ss-presentation-layer). I.e. all he wants is to use the service in a different presentation engine. And if ss-service is well designed then I just don't see why it should make a difference to you that he want's to use it.

Another thing I take issue with is the tone of the conversation, Ernie has delivered code (that I think leverages the existing infrastructure well), seems to be pretty responsive and thoughtful about how things are done, and is moving things forward. I don't think it's at all accurate to characterize what he is doing as "cowboying in on our SS initiative" or to say he has been amazingly insulting towards you.

As Roc said, Ernie has a problem he needs to solve; he is going to do what he needs to do to get it solved and even if you don't agree with his priorities, I would hope you could recognize that your goals and his are sufficiently aligned that the work you do can be complimentary.