coapp-developers team mailing list archive

[Mark Stone <mark.stone@xxxxxxxxx>]

I have been looking at Odata a fair amount in my "day job" as a good
example of Microsoft trying to do the right thing on the
ever-more-important issue of open data. And it isn't just a Microsoft
thing; check out Netflix's ue of Odata (more PoC than anything else,
but still....).

Having said that, the Odata stuff is pretty new and not fully baked
yet. That's good news and bad news. The bad news is that it doesn't do
everything one might want in the most elegant way (as Trent noted).
The good news is that the Odata team at should be pretty open to input
and its early enough for them to still make changes.

I can connect you guys to the Odata developers if that would be helpful.

-Mark

On Thu, May 20, 2010 at 7:49 AM, Trent Nelson <trent@xxxxxxxxxxxxx> wrote:
> Howdy,
>
> Garrett and I started taking a look at the XML schema stuff for package
> metadata on Monday.  That led us to looking into how we could leverage Atom
> feeds, which led us to OData (odata.org).  After a bit of playing around, we
> came up with a reasonably elegant approach for leveraging an Atom-oriented
> package browser via OData that you can navigate and interact with using
> nothing more than your web browser.  Using the patterns presented by the
> examples on the odata.org website, our idea was along the lines of:
>
> a) http://odata.coapp.org/odata.svc/: this would be a server-side OData
> provider that would expose our package info (data and metadata) to the
> world, via an OData-compliant web service.
>
> b) http://browse.coapp.org/: a very simple web app that abstracted the
> quirky OData query parameter stuff and provided a feed-oriented package
> explorer (i.e. that you would directly interact with via your web browser).
>  At the root site, there would be an Atom feed of package categories/genres
> (i.e. synonymous to the categories cygwin uses to, er, categories individual
> packages ('Development', 'Web', '.NET Libraries', 'Productivity', 'Network',
> etc)).
>
> This feed would be generated by a query to the odata.svc along the lines of
> http://odata.coapp.org/odata.svc/categories.  Once you select a category
> from the feed, i.e. 'Development', the browse.coapp.org web app sends
> another request to the odata.svc using the OData query facilities
> (http://odata.coapp.org/odata.svc/categories?name=Web), and wallah, you get
> presented with another feed of all available packages in that category, with
> links to relevant .msi's for download.
>
> At least, that's what we came up with after our extensive 15 minute
> investigation of OData ;-)
>
> The SDK page (http://www.odata.org/developers/odata-sdk) has a link at the
> bottom where you can download a pretty neat .NET implementation that
> demonstrates how all this works in practise:
>
> http://www.odata.org/developers/odata-sdk#/media/7570/odatasdkcodesamples.zip
>
> I had a quick play around with it.  They provide two sample OData services
> that can be exposed: Northwind.svc and OData.svc.  The former is identical
> to the SQL Server Northwind database -- in fact, the project actually
> creates a SQL Server database when it's first run, which is where all the
> actual data is stored that they're exposing.
>
> The latter, OData.svc, programmatically constructs both the OData metadata
> and the subsequent run-time data, via C# code that uses the
> 'DataServiceProvider' library, included in the sample solution.  e.g.
>
> <code>
> _metadata = new DSPMetadata("DemoService", "ODataDemo");
>
> // Address Complex Type
> ResourceType address = _metadata.AddComplexType("Address");
> _metadata.AddPrimitiveProperty(address, "Street", typeof(string));
> _metadata.AddPrimitiveProperty(address, "City", typeof(string));
> _metadata.AddPrimitiveProperty(address, "State", typeof(string));
> _metadata.AddPrimitiveProperty(address, "ZipCode", typeof(string));
> _metadata.AddPrimitiveProperty(address, "Country", typeof(string));
>
> <snip>
>
> suppliers.Add(CreateResourceObject(suppliersSet.ResourceType,
> supplierPropertyList,
>                0, "Exotic Liquids", 0, CreateResourceObject(addressType,
> addressPropertyList, "NE 228th", "Sammamish", "WA", "98074", "USA"), new
> List<DSPResource>()));
>
> suppliers.Add(CreateResourceObject(suppliersSet.ResourceType,
> supplierPropertyList,
>                1, "Tokyo Traders", 0, CreateResourceObject(addressType,
> addressPropertyList, "NE 40th", "Redmond", "WA", "98052", "USA"), new
> List<DSPResource>()));
> </code>
>
> Now, this is the point that my 15 minutes of experience with OData let me
> down.  The C# approach for whipping up both metadata and data seems, er, to
> not be particularly flexible.  We'd have to update the code and redeploy the
> web apps every time we added a package.  The SQL Server approach is
> obviously a lot more flexible, but it seems kinda' heavy weight -- we'd need
> to design a database schema and associated tools for managing all of our
> package data and metadata (note that this is possibly the best long-term
> solution, waaay down the track).
>
> Anyone know if there's an option available to us that's in the middle?
> If we could just store all of our package data and metadata in some XML
> files, at least initially, that seems like it'd be the quickest way for us
> to hit the ground running, so to speak.  From my quick grok of the
> DataServiceProvider project, I didn't see an obvious way to do this.
>
> So, to the question alluded to in the subject, anyone out there with some
> OData experience that could shed some light on our options?
>
> Regards,
>
>        Trent.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~coapp-developers
> Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~coapp-developers
> More help   : https://help.launchpad.net/ListHelp
>