coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

I'd be quite happy with an ASP.NET MVC  CMS too ... an all-in-one solution based off of Orchard (which is what NuGet is using for the package server anyway) would suit me just fine.

(fyi, I'm pretty sure that WCF is what drives the OData underneath all that for NuGet's package server)

I'm going to get my wisdom teeth out in a couple of hours. If I survive, perhaps we can skype about this later.

G

From: nasserd@xxxxxxxxx [mailto:nasserd@xxxxxxxxx] On Behalf Of Nasser Dassi
Sent: Tuesday, February 22, 2011 10:33 PM
To: Garrett Serack
Cc: adam@xxxxxx; coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Package Server Implementation

Hi guys,

Any progress on this?

The reason I ask is, well, cuz the new coapp-org site is not up yet... and I'm finding specific CMS solutions/platforms getting more relevant updates than the one we woulda used.

NuGet even updated to 1.1 the weekend after their 1.0 release -- which was when Garrett first created this email thread.

What am I saying?  I can reliably piece together an ASP.NET<http://ASP.NET> MVC 2- or 3-based website/CMS with all the necessary bells and whistles (including OData/Atom/RSS/NuGet shtuff) ... and it can be based off of Orchard, which also hit 1.0.  Heck, there's really no need for WCF for what CoApp is looking to accomplish.

Thoughts?

(Also, Garrett, the more I look at the "base" theme the more I dis-like it...... so a new design may be warranted...)

- nasser
On Sun, Feb 13, 2011 at 9:45 AM, Garrett Serack <garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>> wrote:
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:adamkennedybackup@xxxxxxxxx<mailto:adamkennedybackup@xxxxxxxxx>]
Sent: Friday, February 11, 2011 10:56 PM
To: Garrett Serack
Cc: Philip Allison; Olaf van der Spek; coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
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 <garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>> 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<http://ASP.NET>,
> Orchard (a CMS framework built on ASP.NET<http://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:mangobrain@xxxxxxxxxxxxxx<mailto:mangobrain@xxxxxxxxxxxxxx>]
> Sent: Thursday, February 10, 2011 4:05 PM
> To: Olaf van der Spek
> Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>; 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@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~coapp-developers
> More help   : https://help.launchpad.net/ListHelp
>
>


_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp