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

[Steve M. <sm...@CS...>]

notwithstanding the fact that this is an implementation point rather than
architecture, we shouldn't worry too much about exposing the list of all
slices to arbitrary users given that any old joe can suck it down as an
xml file.  when we change how the DB is exported to Node Manager we can
start to think about whether we need to keep slice info compartmentalised.

steve



On Tue, 27 Jan 2004, Timothy Roscoe wrote:

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