up2date development

[Alan Milligan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| Alan Milligan <alan at balclutha.org> writes:
|
|>> As stated earlier, we have a firm agenda to ensure up2date remains both
|>> that current with Python and a generalised rpm gui tool.
|
|
| Who is 'we'?  What is your goal?
|

Over the next couple of years we are hoping to further develop and roll
out our web-based Python/Zope/Plone ISP and CRM products
internationally.  There are considerable complexities in ensuring all of
the constituents are in place for the modules to work.

RPM is the perfect tool for us to manage these dependencies and manage
large-scale deployments.

We also have a client who is controlling the software upgrades of their
remote network perimeter management clients, also using our RPMManager.

|
| I've not not heard anything about removing openssl or rpclib, much
| less justification for calling them sins.  I suspect you don't fully
| understand the constraints and requirements on up2date to really say
| for sure what can or can't be removed (which, to be fair, is hard to
| know unless you're in RHN as most of those are internal constraints
| and requirements at a business or technological level).
|
Those bits aren't the sins I was refering to (they would be the bits
where someone allowed system administrators to write OO code -
packageList.py for example).

up2date has been around since 1.5 when there was no ssl socket support
within Python, the SecretLabs xmlrpclib stuff wasn't part of the core
then either.

ssl support is now native, so it would make sense to use it.

The rpclib code also unfortunately contains the artifact that whoever
implemented it completely failed to realise that there is basic http
authentication support within XML-RPC.  It is simply a matter of placing
a colon-delimited user/password in the url.

All of code defining and plugging in those proxy transports is
irrelevant.  We can greatly simplify the code base by removing it.
xmlrpclib is reliable and very well understood.  I'd not be so sure
about what's in the up2date 'extensions'.


| up2date is not an open source project.  It is open source -software-
| (feel free to embrace/extend it all you want), but to date it has been
| developed strictly in-house in RHN to meet specific Red Hat goals.
| That could conceivably change, given the right set of circumstances,
| but it would need to line up with the goals RH and RHN have in mind
| for up2date (or, at the very least, not be contrary to those goals).
|

I absolutely agree.  I am quite confident I understand RH's position on
this with regard to the real IP of it's business and the competitive
advantage it derives from these technologies.  We take a very similar view.

We already have a up2date client with all of the afore-mentioned changes
which meets our objectives.

However, if we remain aligned with RH/Fedora, then clients can access
our channels with existing software.    They can also still connect to
RH to get their OS layer, which they may prefer.

This is certainly an attractive proposition to us, and we've thus
approached you regarding merging some of these changes as (i) they do
represent a fairly logical maintenance path for this software anyway;
(ii) the cost to us of retro-fitting is about the same as contributing.

We are certainly prepared to make available resources both now and in
the future to facilitate whatever we can agree.  Let's continue talking
to see exactly what that is.

Regards, Alan


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBbcifCfroLk4EZpkRAtq9AJ0Xpg38s8jsCFPkIT+WPwWmqFfcLACfe7PE
dE9d6D9WU2r6kMKnvKy5ubs=
=fkmm
-----END PGP SIGNATURE-----