Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: Current server and BitTorrent protocol

Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

current
Discussion topic

Back to topic list

Re: Current server and BitTorrent protocol

Reply

Author jwbernin
Full name John Berninger
Date 2003-04-21 16:44:38 PDT
Message Tom -

        As I see it, there are a couple problems with this approach.
First, attempting to integrate two transport methods for package
distribution into a single server would be a nightmare. The Current
server no longer does /any/ package or header transports - all of that
is entirely handled by Apache. In effect, attempting to integrate
BitTorrent would move us back to a non-Apache solution, thereby reducing
the number of clients Current can handle. As a developer, I'm
vehemently opposed to this type of move backwards.

        Second, we're haqving a hard enough time keeping Current updated
with new versions of the client as it is - adding support for a modified
client would increase the complexity to a level that I personally am not
willing to work on. (Hunter, I appreciate the challenges you faced
coming up with the project name, but it's giving me headaches making my
grammar not do strange things!)

        Third, and perhaps most important from my point of view, using
up2date / Current for this apprach just seems wrong to me; the behavior
of multiple repositories you're looking for doesn't offer any real
advantages that I can see over what up2date / Current provides. In
addition, if you really want multiple repositories, you should probably
look at how Debian's apt-get works; what it seems to me you're trying to
do is re-write apt-get to use the up2date command. It'd be easier to
just "ln -s up2date apt-get".

        I just can't see any advantages to trying to move from HTTP to
BitTorrent with up2date / Current, and I do see a whole mess of
headaches waiting for a person to happen to.

On Mon, 21 Apr 2003, Tom Jennings wrote:

> I wrote a while back about expanding the utility of Current and up2date,
> to support more than (more or less) emulating the distribution of RedHat
> RPMs, to include general RPM distribution.
>
> I realize you guys are busy, and any code changes are up to me, just to
> state the obvious.
>
> My goal is to make Current/up2date (1) more general and (2) incorporate
> BitTorrent for distributed download. I know you've got other things to
> do, but if done cleanly etc, are you willing in principle to incorporate
> BitTorrent support if I provide patches and documentation? Clearly you'd
> wait'n'see if the result is worth your bother, but do you have any
> up-front objections?
>
>
> Up2us, my extention to up2date, currently can
> * fetch the SSL certificate and GPG keyring from the server
> * install both,
> * register with Current,
> given only the servername.
>
> This would seem useful for Current as it stands. Up2date remains 100%
> untouched, and up2date config 100% untouched and fully backwards
> compatible.
>
> up2us-1.1 does this now. This version does not support BitTorrent.
>
> It's a wrapper around up2date (both command line and GUI), essentially,
> which technique you comment on unfavorably before; I disagree, I think
> it's the safest and most stable. Existing up2date config -- if any -- is
> paranoiacally preserved. It should work with client 2.7 - 3.x, and RH 7
> or 8(9). It's exceedingly clean, install-wise, it creates and upgrades
> it's own config, uses PAM and consolehelper, etc.
>
> Adding BitTorrent support requires changes to Current and up2date. I
> fully understand and agree with your attitute towards the client. No
> problemo here, it's the perfectly correct approach for Current.
>
> But if I produce patches that incorporate BitTorrent into Current,
> cleanly, then:
>
> * Your goals for Current are unaffected by my stuff,
> * Current can be deployed more broadly, for general software
> distribution, with the stock client (RH-shipped) or the modified client
> (BitTorrent-enabled).
>
> Since RedHat Inc has recently entrenched up2date in their income model,
> it's likely they'll balk at incorporating my BitTorrent patches, which
> goes around the central-server model for software distribution, so I
> will own the patched version, most likely.
>
> Client changes would not affect Current in any way, since you would
> continue to test against the RH-distributed client of course.
>
> Feedback? Thanks for your time.
>
> tomj
>
>
>
> Up2us, extention of up2date client:
> http://sourceforge.n​et/projects/up2us
>
> BitTorrent protocol:
> http://sourceforge.n​et/projects/bittorre​nt/
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
> For additional commands, e-mail: dev-help at current dot tigris dot org

--
John Berninger

GPG Key ID: A8C1D45C
        Fingerprint: B1BB 90CB 5314 3113 CF22 66AE 822D 42A8 A8C1 D45C

Sit vis nobiscum.
--

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
For additional commands, e-mail: dev-help at current dot tigris dot org

« Previous message in topic | 2 of 6 | Next message in topic »

Messages

Show all messages in topic

Current server and BitTorrent protocol tomjennings Tom Jennings 2003-04-21 12:39:23 PDT
     Re: Current server and BitTorrent protocol jwbernin John Berninger 2003-04-21 16:44:38 PDT
         Re: Current server and BitTorrent protocol tomjennings Tom Jennings 2003-04-22 16:15:22 PDT
             Re: Current server and BitTorrent protocol hunterm Hunter Matthews 2003-04-23 08:03:28 PDT
                 Re: Current server and BitTorrent protocol tomjennings Tom Jennings 2003-04-23 11:58:35 PDT
         Re: Current server and BitTorrent protocol tomjennings Tom Jennings 2003-04-22 16:17:55 PDT
Messages per page: