Hmmm. While OData only pulls the records which it needs based on the Query, you are correct about it being a little less that tight on space usage.
I'm pretty confident that the client engine is sufficiently thrifty to not pulling records it doesn't need, but if the packing of OData isn't sufficiently tight (which, let's face it, it's not slim), we can pretty trivially support another wire protocol (binary stream) with very little effort (since the .NET OData is built on WCF). Now, that being said, I'd be really surprised to find in practice that the bytes-on-the-wire are actually going to be that bad.. gzip compression should mask a lot of the OData incompetence^h^h^h ... er fat packing... I'll add a todo to examine the actual bandwidth consumption on larger streams down the road... G -----Original Message----- From: Adam Kennedy [mailto:adamkennedybac...@gmail.com] Sent: Friday, February 11, 2011 10:56 PM To: Garrett Serack Cc: Philip Allison; Olaf van der Spek; coapp-developers@lists.launchpad.net Subject: Re: [Coapp-developers] Package Server Implementation This is the point where I make a (rare) appearance and remind you again that Atom probably isn't going to take you past about 1000 packages, and the future beyond that is something that packs data tighter, not just pulling less equally fat data :) Adam K On 11 February 2011 11:18, Garrett Serack <garre...@microsoft.com> wrote: > 3) The server I speak of is a package server. While CoApp allows > you to have package feeds expressed as merely XML-based Atom feeds > (which can be entirely statically generated) we also want to support > OData (which shares some minor detais with Atom, but don't ever get > the idea that OData and Atom are in any way usefully related > [grrrrr*]). OData gives us the ability to use some simple REST > mechanics to query the server for packages based on criteria without > having to download the whole damn feed's worth of data > > The package server that the NuGet folks put together uses ASP.NET, > Orchard (a CMS framework built on ASP.NET) and c# to provide for > uploading, downloading and management of packages at the server, and > exposes their package information over an OData interface. All that > needs to be done, is the OData interface has to be changed to pull > data from CoApp packages instead (which is pretty trivial once I > release the binaries for the engine[VERY SOON], and serve up packages for > consumption. > > I have some farther reaching ideas about server-to-server package > mirroring which we could build on top once the basic serving is done. > > > > G > > > > From: Philip Allison [mailto:mangobr...@googlemail.com] > Sent: Thursday, February 10, 2011 4:05 PM > To: Olaf van der Spek > Cc: coapp-developers@lists.launchpad.net; Garrett Serack > Subject: Re: [Coapp-developers] Package Server Implementation > > > > ASP is a server-side language, yes. Not a language in which one would > write a server. To me, a server is a long-running process which deals > directly with network clients, not a bunch of code for dynamically > generating content on top of an existing web server. > > Of course, I could be wrong about ASP (I don't use it), or Garret > could be using a different definition of the word server... hence the > question. :) > > _______________________________________________ > Mailing list: https://launchpad.net/~coapp-developers > Post to : coapp-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~coapp-developers > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
