coapp-developers team mailing list archive

[Trent Nelson <trent@xxxxxxxxxxxxx>]

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.