-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 24 February 2003 10:36 pm, fish wrote:
> Ideally, we'd have a free sun v1.4 quality
> JVM, or at least sun v1.4 would build fred (btw, if anyone knows how
> to make it do this, can you please tell me? java 1.3 really
> hates my system).
Try
On Sun, Feb 23, 2003 at 03:44:53PM -0500, Jay Oliveri wrote:
> On Sunday 23 February 2003 02:37 pm, Ian Clarke wrote:
> > What is the point in forcing every client author to reimplement FEC
> > when the FEC code is already present within Fred?
>
> It is kludgy to say the least if you're inserting
On Sun, Feb 23, 2003 at 11:40:51AM -0800, Ian Clarke wrote:
> > AutoRequester), run in a separate VM if we run the client code separate
> > from the node, and with its own port. It might be a superset of low
>
> I am not sure I will ever understand those that argue that we should
> run different t
On Sun, Feb 23, 2003 at 04:11:13PM -0500, Jay Oliveri wrote:
> Small misunderstanding..
>
> On Sunday 23 February 2003 03:51 pm, Ian Clarke wrote:
> > > It is kludgy to say the least if you're inserting data into Fred from
> > > another machine. The data sent back and forth over the wire (even
>
Small misunderstanding..
On Sunday 23 February 2003 03:51 pm, Ian Clarke wrote:
> > It is kludgy to say the least if you're inserting data into Fred from
> > another machine. The data sent back and forth over the wire (even
> > through localhost) is simply unecessary and wasteful.
>
> Is this an
> It is kludgy to say the least if you're inserting data into Fred from
> another machine. The data sent back and forth over the wire (even through
> localhost) is simply unecessary and wasteful.
Is this an argument for or against doing FEC in Fred? It looks like it
is for.
> Also, using Fre
On Sunday 23 February 2003 02:37 pm, Ian Clarke wrote:
> What is the point in forcing every client author to reimplement FEC
> when the FEC code is already present within Fred?
It is kludgy to say the least if you're inserting data into Fred from
another machine. The data sent back and forth ove
> to do with node/, so it _may_ make sense to run it on a separate port,
> and keep low-level FCP simple.
Well, I certainly agree that we should make a distinction between "low
level" (or Level 1) FCP (what we have now), and higher level FCP (say,
with splitfile support, redirect support etc) (l
On Sun, Feb 23, 2003 at 11:40:51AM -0800, Ian Clarke wrote:
> > AutoRequester), run in a separate VM if we run the client code separate
> > from the node, and with its own port. It might be a superset of low
>
> I am not sure I will ever understand those that argue that we should
> run different t
> AutoRequester), run in a separate VM if we run the client code separate
> from the node, and with its own port. It might be a superset of low
I am not sure I will ever understand those that argue that we should
run different things in different VMs. Requiring more than one
concurrent JVM will o
> I (personally) think FCP does what it does well, and currently don't see any
> real need to add any major functionality. I agree with Gianni; "Adding an
> extra layer that allows client authors to make essentially unbounded
> demands on fred will not improve matters."
Well, I am not sure I b
On Sun, Feb 23, 2003 at 12:36:26PM -0500, Jay Oliveri wrote:
> On Saturday 22 February 2003 08:56 pm, Ian Clarke wrote:
> > > So how about fixing up FCP so that it can handle the FEC/splitfiles
> > > just as automatically and transparently as fproxy?
> >
> > This was more-or-less the motivation for
On Saturday 22 February 2003 08:56 pm, Ian Clarke wrote:
> > So how about fixing up FCP so that it can handle the FEC/splitfiles
> > just as automatically and transparently as fproxy?
>
> This was more-or-less the motivation for having different FCP "layers",
> each providing a higher-level API. U
On Sun, Feb 23, 2003 at 02:25:48PM +1300, David McNab wrote:
> Hi,
>
> While FCP is comfortable for most things, it's painfully low-level when
> it comes to FEC/splitfiles.
>
> The logic for FEC/splitfiles is already in Fred, because FProxy uses it.
Yes, but I am very confident that you don't wa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 22 February 2003 08:25 pm, David McNab wrote:
> Hi,
>
> While FCP is comfortable for most things, it's painfully low-level when
> it comes to FEC/splitfiles.
>
> The logic for FEC/splitfiles is already in Fred, because FProxy uses it.
>
> S
Hi David:
SplitFile encoding/decoding/insertion/retrieval are extremely resource
intensive operations (memory, CPU, threads, temp space).
The decisions about how to make the relevant resource usage tradeoffs
belongs in the application code. Not in FCP.
Fred barely works as it is. Adding an extr
Hi,
While FCP is comfortable for most things, it's painfully low-level when
it comes to FEC/splitfiles.
The logic for FEC/splitfiles is already in Fred, because FProxy uses it.
So how about fixing up FCP so that it can handle the FEC/splitfiles just
as automatically and transparently as fproxy?
17 matches
Mail list logo
