Documentation & extendability

Nov 21, 2008 at 9:35 AM
Is there any form of official or unofficial documentation for the framework yet? I know the source code is available but I'm wondering if there is anything more comprehensive available. Checking the samples shows a log of stuff being used but without analysing the application & framework source code a lot of it appears to rely on guessing when interpreting its behaviour.
 
I'd also like to figure out just how extendable the framework is. I noticed that classes like the DirectoryPartCatalog isn't marked as sealed yet nothing is overridable nor are any of the internal friends or other mebers marked as protected. I guess the ASP.NET MVC team is spoiling me with extensibility support and I'm hoping this is the route that the MEF team is looking to take as well.

Thank you
Nov 21, 2008 at 12:43 PM

Thanks for the feedback. Currently we don’t have any plans to open up any extensibility points in the catalog though we have considered it. Because we are so low-level in the framework there are considerable implications on any extensibility points that we open up. We will keep it under consideration though. Please add a work item so that other’s can vote. Also, the code for the catalogs will be available, so you are free to create a modified version.

Thanks

Glenn

From: TheCodeJunkie [mailto:notifications@codeplex.com]
Sent: Friday, November 21, 2008 11:38 AM
To: Glenn Block
Subject: Documentation [MEF:40445]

From: TheCodeJunkie

Is there any form of official or unofficial documentation for the framework yet? I know the source code is available but I'm wondering if there is anything more comprehensive available. Checking the samples shows a log of stuff being used but without analysing the application & framework source code a lot of it appears to rely on guessing when interpreting its behaviour.

I'd also like to figure out just how extendable the framework is. I noticed that classes like the DirectoryPartCatalog isn't marked as sealed yet nothing is overridable nor are any of the internal friends or other mebers marked as protected. I guess the ASP.NET MVC team is spoiling me with extensibility support and I'm hoping this is the route that the MEF team is looking to take as well.

Thank you

Read the full discussion online.

To add a post to this discussion, reply to this email (MEF@discussions.codeplex.com)

To start a new discussion for this project, email MEF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Dec 2, 2008 at 6:09 AM
@gblock - I'll reply here instead of on Twitter because of the obvious space limitations which it imposes. I'll be the first one to admit that I've had limited time to explore MEF in full, something I hope to get some time to do over x-mas vacations. The one point I've started looking into is the one I mentioned in my initial post in this thread; extending catalogs.

Here are a couple of "concerns" I have. The first thing I looked into was to add sub-folder watching of the DirectoryPartCatalog class, because a decent extension system should offer the ability to store extensions in a common folder but enable them to be stored in their own folder so that any resources they use can be stored there as well, keeping a clean folder structure and avoiding conflicting file name and so on.

So I load up the source file and have a look around at what the class will let me do. Great it's not sealed so I should be able to derive from it and alter the behaviour. Turns out this wasn't as easy as it sounds because all fields are marked as private and pretty much everything is either non overridable or private. So even deriving from the class leaves me with little option to actually alter the behaviour.

This closed design can be found in all of the catalogs. Yes, it is true that the source code is available and that I could copy the code it self and roll out my own version but then I loose the ability to take advantage of polymorphism at a sub-class level. Anothing thing about this approach is that I want to make a sligh modification to the existing behaviour, I don't want to be forced to maintain a parallell copy of the source code.

Then we have the issue reported at http://www.codeplex.com/MEF/WorkItem/View.aspx?WorkItemId=6682 about having classes such as ReflectionCacheService makes as internal. This even makes it impossible to just copy the code of an existing catalog, give it a new name and make some modifcations to its behaviour, because the helper methods defined in ReflectionCacheService isn't available to me so I would be forced to maintain a parallell copy of these methods as well.

Ultimatly you could derive from ComposablePartCatalog but that doesn't change the facts that I would have to maintain parallell copies of the code just to make a slight modification nor does it remove the issue with ReflectionCacheService not being accessible.

I fully understand and respect that all aspects of a framework can't lend them selves to extensibility points but catalogs (just to name one) sure is a "surface" member of the framework, one that the end user is likely to want to alter.

It might sound like a broken record by now but the ASP.NET MVC framework is just as "low-level" as the MEF and it offers pretty much full extensibility. Don't like how a feature works? Replace it!

Making proper use of protected members, overridable members, interfaces and  incresingly fine grained inheritance (enables the consumer to derive at the right level) chain will enable people to extend the framework in a frictionless way.

If you make it cumbersome to extend the behaviour in the framework then you way risk people building their own flavour with the available source code and that can't be the goal? It would be better to make everyone use the same code base as much as possible and monkey patch the parts which they need/want to modify. 
Dec 2, 2008 at 9:49 AM
Code Junkie's comment also gets my vote.

Either that, or I'd like to see a version of the DirectoryPartCatalog which supports nesting of addins in child folders of the specified addin folder.

Given MEF's aim's of targetting composable applications, the current addin deployment support is not (IMO) sufficient.  Potential naming collisions between addin assemblies and/or their assembly or other file dependencies means MEF really needs to support nested folders for addins.

Without nesting, you can't really reliably support seperate deployment of addins.  Which ends up meaning you are forced to package and deploy addins with the host app removing a primary benefit - the ability to install addins at a later data *after* installing the host.

Admittedly you can kind of get around this right now by searching for subfolders of your addin directory and creating an aggregate catalog with a directory part catalog for each found subfolder.  This is kind of messy though, and from what I can tell, looks like it would result in loss of support for caching.

There are other deployment related issues which I'd like to see some attention paid to, some of which System.Addin covered - one is tool support for identifying and isolating contracts from implementations so that dependencies can be controlled and managed during development.

Related to this, the ability to load Addins into a separate AppDomain is valuable for detecting and controlling dependencies.

Regards,
Phil

Dec 2, 2008 at 6:36 PM
Edited Dec 2, 2008 at 10:00 PM

Hi guys

First let me say thanks for the feedback on the extensibility points. We are certainly aware that there is a desire to have additional extensibility points in the catalogs. We actually already have added several known extensibility points into the framework.

1. Catalogs themeselves inherit from a base ComposablePartCatalog, thus allowng you to create whichever custom catalogs you deem necessary.
2. Export Providers are completely extensible.
3. Our primitives layer consisting of ComposablePart / ComposablePartDefinition / ExportDefinition / Export allows you to completely change the programming model of MEF itself (i.e. get rid of attributes, etc)

Opening up extensibilty points may sound simple, but the devil is in the details.

First we have to be very careful in that once we open up anything in the framework we CANNOT close it again. This is a product of being so low in the stack. That means we have to be absolutely sure before we open up anything. In general for this reason we usually resist opening up any holes that can't be closed later until it has gotten in the wild and been used in  many implementations. We need to be selective and make decisions based on the usage across the board in  the frameowork. MEF will be broadly adopted in WPF, Winforms, ASP.NET, Web Services, and probably some console apps.

Second, there are costs of opening up extensions. What are those costs? Testing, lots of testing. We have many product and platform teams at Microsoft that are directly depending on MEF We have to make sure that opening up any of those points doesn't introduce security holes, or impact Quality of Service of the components / apps that will build on top of us. This means we have rigourous testing in terms of security, perf, etc for each point we open.

We will be evaluating all the feedback we receive and potentially adding more extensibility points in the future before we ship. We do have limited resources, so we will look at that feedback across the board and prioritze based on what is practical. What we try hard to avoid is adding extensibility points that are not asked for and that will not be used.

One thing I would suggest is to take advantage of MEF Contrib (http://codeplex.com/MEFContrib). One of the things that was great that happened in the case of MVC was the community took advantage of MVC contrib to create extensions. As the source for MEF is out there, it would be very easy for someone to go and copy the source and create a set of catalogs in contrib that meet the extensibility requirements you are asking for. That implementation can become a community standard. If the community is making heavy use of contrib, that provides great evidence back into our development efforts (as it has MVC) that it is something we should consider.

Thanks for the feedback, we really appreciate it and are listening.
Glenn

 

Dec 3, 2008 at 1:49 PM
@Glenn,

Thank you for your reply. I understand the potential complications which follows more extensibility points, but I feel that at least the catalog section has a couple of limitations in it's current form. 

Like I mentioned before, even if I took the complete source code from one of the shipped catalogs, pasted it into a new file, slapped on a new name and changes one line of code (like making the filewatcher recursive, just to provide an example) it still wouldn't compile because the ReflectionCacheService is marked as internal. This would mean I would have to reproduce that entire code base as well.

Maybe this could be solved by introducing a second lay of abstraction so the inheritance chain is

ComposablePartsCatalog {abstract} -> CachedComposablePartsCatalog {abstract} -> DirectoryPartsCatalog/AttributedAssemblyPartsCatalog/...

Where the CachedComposablePartsCatalog would implement the ICachedComposablePartCatalog and provide the nessecary abstractions needed to deal with the caching (which is repeated across the shipped catalogs right now), then the members of ReflectionCacheService could be left internal if that's a requirement and at the same time provide a simple approach to create your own catalogs.

You would then be able to copy a shipped catalog and make modifications to it. That said, I still think that the catalogs are surface members of the API and wouldn't impose any security vulnerabilities or add complexity to the consumption of the API if they were designed to be able to inherit from (protected members, overridable members - where suitable), would it?

It would remove the need to maintain almost duplicate code bases and it would also let you extend the inheritance chain and take advantage of polymophism.


-- Slight derailment --
Are there any documentation of the Export Providers? I'd like to learn more about them and how to implement my own / know when its a good practise to implement my own.