-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
| Alan Milligan <alan@xxxxxxxxxxxxx> 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-----
