RE: [Planetlab-arch] Proposed Changes for Dynamic Slice API

[Timothy R. <tr...@in...>]

Seconded (as long as the performance is OK). 

 -- Mothy


At Mon, 26 Jan 2004 15:41:50 -0800, "Adams, Robert" <rob...@in...> wrote:
> I thought the original philosophy was to not put query like operations
> into the foundation APIs -- these operations are best handled by some
> 'service' which sits on top.
> 
> Rather than wedging regexps into the Dynamic Slice API, it seems better
> to let them return what they return and to add filtering capability to
> the command line invokable programs that interface to the API.
> 
> The 'auth' capability should be added to the API since that is not
> something that an external service can figure out and that we wish to
> control.
> 
> -- RA
> 
> -----Original Message-----
> From: pla...@li...
> [mailto:pla...@li...] On Behalf Of Timothy
> Roscoe
> Sent: Monday, January 26, 2004 11:27 AM
> To: pla...@li...
> Subject: Re: [Planetlab-arch] Proposed Changes for Dynamic Slice API
> 
> 
> At Mon, 26 Jan 2004 14:18:24 -0500, Vivek Pai <vi...@CS...>
> wrote:
> > Sedayao, Jeff wrote:
> > > The parameters are optional parameters, so that scripts depending on
> the
> > current
> > > behavior are not broken.  The purpose of these changes is to simply
> the
> > writing
> > > of scripts.  For the listSlice options, we also get a tradeoff of
> less
> > network
> > > bandwidth and less CPU on the querying machine for more CPU usage on
> the
> > > PlanetLab web server.
> >
> > Just my two cents, and I'll admit that the relevance may be remote,
> but
> > I would be very wary of anything that pushes work onto the server
> side.
> > In particular, when I was at iMimic and we were playing around with
> some
> > of the regexp libraries on Linux, performance ranged from mediocre to
> > dismal. In particular, I recall that some libraries could only do
> about
> > 50-100 matches/second on a 1 GHz machine.
> >
> > In terms of bandwidth versus CPU, it would be interesting to see how
> > compressible this data is using gzip. That way, you could compress the
> > file, send it over, and have the client do the regexp processing. This
> > way, whoever is consuming the resources gets to "pay" for it.
> >
> > Just a random opinion - feel free to ignore it.
> 
>   Good point.  We should also look at how this tradeoff scales,
> as the number of slices/PI, users/slice, and nodes/slice goes up.  But
> in general, the principle of offloading processing to clients if it
> means no loss of security and the bandwidth is available is an
> important one.
> 
>  -- Mothy
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Planetlab-arch mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/planetlab-arch
> 
> 
>