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

[Adams, R. <rob...@in...>]

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.
>=20
> 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.
>=20
> 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.
>=20
> 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.=20

 -- 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