[EMAIL PROTECTED] wrote:
Brock,
Group 1:
All of our code amounts to an API
The GUI, the CLI, and the backend all live in the same gate so it's
reasonable to check all changes made to all functions
The problem we've been having is essentially a social one which is best
solved through better testing, diligence in code reviews and discipline
when writing the code in the first place
By the time an adequate API is in place, it will duplicate the object
structure of the back-end anyway
The solution is to (as Tom said) improve exception handling, move UI
stuff, move logic into the back end, improve documentation
This position isn't tenable or realistic. We do have code in our gate,
but currently, there's no way to tell what interfaces ought to be used.
This is an unfortunate consequence of using Python which doesn't have
the language support for enforcing encapsulation. However, good
documentation (or any documentation at all) and the underscore
convention can go a long way to solve this problem. A new API isn't
needed to do that.
Many classes need refactoring. If a new team were to show up and look
at the existing CLI and GUI code, I suspect they'd be utterly mistified
about how to procedd writing a 3rd client that uses the "interfaces"
that allegedly exist.
A new team (Update Center 2 toolkit) has shown up and looked at the
existing CLI and GUI code and has proceeded to write a 3rd client
(updatetool) that uses these interfaces. I've integrated several drops
of pkg(5) with this client over the last 7 months, and while each time
it has been necessary to make some changes to the client to make it work
with the new drop, this hasn't been difficult at all. In fact, I've been
quite impressed with the "prototype" nature of pkg(5) that the APIs have
been as stable as they have been. The IPS team should be congratulated
on evolving this software in such a smooth fashion. We do have our own
abstraction layer in the GUI that tries to isolate the GUI code from
pkg(5) API changes, but this abstraction layer is customized to the
updatetool and isn't intended to be general purpose at all.
The problem is partially social, but we've already tried social
solutions. We still have duplicated code, unclear interface boundaries,
and unintended breakage. We've tried Group 1's solution, and it wasn't
adequate.
So how do we go forward? This is important because a) we told the GUI
team we'd have an API for them and if we want it being used by
november, this needs to move quickly b) I thought this was a high
priority item in terms making the code safe.
You may have to go forward without consensus. You're the one doing the
work, ultimately the decision is up to you.
This does effect the whole project because once the second API is there
(call it the external API), then it has to be maintained (enhanced,
etc.) whenever a change is made to the internal API.
Tom
You're an advocate of
Postion 2. I think you're correct. The more time you spend arguing
with people who won't change their mind, the less time you have to write
code. If they think they can do a better job than you can, let them
code up an alternate solution.
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;SWI Install/Update Software
adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA
email;internet:[EMAIL PROTECTED]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-916-9943
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
