FW: using aspen in ag

[Ivan R. Judson]

I'd like to consdier these diffs for submission into our cvs, but I'd like
to make sure there isn't something we need to either a) learn from the diffs
or b) modify to make more general for other developments like this.

Aspen is an application level networking layer built on mash stuff, by
Andrew who's at berkeley.edu.

--Ivan 

-----Original Message-----
From: Andrew Swan [mailto:aswan at cs.berkeley.edu] 
Sent: Tuesday, October 19, 2004 8:04 PM
To: Ivan R. Judson
Subject: Re: using aspen in ag

Ivan R. Judson wrote:
> I would like to see what modifications you need to the existing 
> toolkit, we're in the process of doing the AGTk 3.X release, which 
> should significantly simplify certain aspects of the software. The 
> networking could still benefit from aspen or an aspen-like sysetm however.
> 
> I'd like to be sure we have what you need in the next version of the 
> software. Can you send me the modifcations you've made and I can see 
> if I understand what's going on? I'll then either accept the mods as 
> something we can do exactly, or propose a slight modification.

i've put a patch that should apply cleanly to the latest cvs as of this
afternoon at:

  http://www.cs.berkeley.edu/~aswan/ag.patch

these do not include the media tools patches, we can talk about those
separately if/when you're interested.  i'll try to summarize rather than
just giving you a pile of diffs to decipher:

there is now a new subclass of NetworkLocation called AspenNetworkLocation.
unlike UnicastNetworkLocation and MulticastNetworkLocation, an aspen
location does not contain an address and port, just a url.  there were a few
places in the code that assume that any NetworkLocation has addr and port
fields.  i'm not sure i caught all of them but the most common thing was
doing comparisons of two NetworkLocation objects by comparing all the
fields.  i fixed this by adding an equality operator to the NetworkLocation
subclasses.
(that's the diffs to Descriptions.py, NetworkLocation.py, Venue.py, and
AGService.py)

the diffs to VenueServer.py allow the LoadPersistentVenues method to
recognize aspen locations when the server is stopped and restarted.

in VenueClient.py, i just hardcoded the rule that any client can always use
an aspen url.

the diffs to services/node/AudioService.py and VideoConsumerService.py
launch the media tools with the right arguments when given an
AspenNetworkLocation .

finally, the most extensive changes in terms of number of changed lines are
in VenueManagement.py.  this is where my poor ui design skills shine through
:-)  i did a fairly hacky job here of adding support in the management ui
for aspen urls.


i guess the big picture issue is the generalization of the NetworkLocation
class and breaking the assumption that a NetworkLocation always contains a
literal address and port.
i'm not sure if this has other implications for the ag codebase.

anyway, thanks for your response, i'm looking forward to your comments!

-Andrew