another approach to what current does

Hello.

Recently i had some free time, and a farm of 9 linux systems on a production
site, which i was sick to update the regular way from RHN. I have tried some
other soulutions like yum, but they didn't seem solid enough for me, so i
said to myself - let's take a look at what up2date does and how it talks to
the server - all i need is one server downloading the updates into my
internal network, and others pulling it from him. At the time i wasn't able
to locate your project (there are only 92 reverse links on google from your
site, surprising). As we all now, all downloaded stuff is at
/var/spool/up2date , so all i needed to solve the authentication phase of
up2date - that was done by 10-line perl script. I have documented my work,
and posted it at www.nrh-up2date.com. (Yes, that's Not RedHat's up2date :) .
today your project was brought to my attention, and i took a look at it .
seems much more advanced then what i did, but also with more requirements -
my goal was to make a minimal system (apache + perl + working up2date
client) to become a proxy betrween the up2date content and the up2date
clients on other computers - your's seems to have a database attached to it,
and some more advanced configuration required .

I would apriciate if someone from the developers of current took the 15
minutes to read through my documentation, give some comments, and state if
we could work together . I understand, that i have a much different approach
from you (my server does not require registration, doesn't need database,
works with files only, and relies on content from RHN servers) , but i hope
that we can work together and provide 2 different groups of people with 2
different needs - these who need the advanced tracking (system by system)
functionality you plan to offer will use the Current server, and these that
need only a proxy can use my code . RedHat also has 2 products they sell
that correspond to the proxy idea i implemented, and the enterprise server
(Currnet) which duplicates redhat's RHN functionality for large depatrments.
As i can understand, your solution can have a performance limiting factor,
while mine is based on the apache + 10line perl script - there are no
performance bottlecks.

Regards,
Alex.