Lukas,

(note: I wrote most of this before the presentation last Friday, so some of it is answered or dated.  Just posting it to get the thread moving... -Jay)

Looking at the latest revision of the wiki. The design is progressing well.  I'm definitely liking the emphasis on migrating to a Bundle-centric approach and the drive for simplifying the deployment and storage models while also making things more robust.  A couple of questions/comments:

* The move to Repo-based content authz seems like a good idea that will map well to the current Group-based resource authz.  And therefore should be easily adapted/understood by users (and us).

* I'm a little confused by the unique constraint on (Package.name,Repo) where Package-Repo is ManyToMany.  That would mean I could have different distinct Packages with the same name, in different repos.  But I could also have the same Package in different Repos.  How will I be able to identify a test.war in different repos as being the same app, or different apps with the same name?   This does prevent two different test.war apps in the same repo, which may make sense, but actually maybe it's too restrictive.

Keeping this ManyToMany is probably a good idea as it is analogous to the Resource-Group relationship wrt Repo-based authz.  But then you may need to keep and re-purpose Package.classification as something that can further identify a Package.  Name may not be enough.  The same is true of resources, to identify a resource you can't go by name, the "classifier" is ancestry.

* +1 to removal of ContentSource, we'll need to work out the details of the CSP feature
* +1 to removal of PackageCategory
* +1 to deprecation/removal of PackageType

* With respect to the PackageVersion changes:
**  +1 to removing architecture.  Does this mean we can also kill off the rhq_architecture table?
** I get why you don't want displayName.  But you may want to make this a redundant, immutable field, set to the package name. Not sure, but it may be helpful to not have to join with Package to get the name.
** +1 to removing displayVersion, not sure I see a reason for this, either.
** +1 to removing MD5 if we can.   Maybe it was the only digest we could get for certain remote content?  I don't know.
** license_name, license_version?  These aren't mentioned, can we get rid of them?

* Mime types:
** +1 to the approach, I think this will be very good as the underlying mechanism for moving the model forward.
** I'm not sure the mime-type determination approach can work like it does for bundle types. It can only work if only one server plugin can determine a mime-type, right?  Is this going to be true?  Maybe it is , I'm just asking.

* With respect to Content discovery, you say: "...The latter point is useful for content discovered in the plugins using the Content API (that don't end up in any repo), because it will allow for two "mywebapp.war:1.0" to coexist in the database, each coming from different resource".  This content without a Repo, what is it "attached" to?  How is it tracked/removed/accessed?

* Bundle Consequences:
* We need better terminology for "normal bundle" and "content bundle".  I don't know what it should be but it should likely reflect that some bundles are file-system/generic/bundle-distribution-file-zip/bundle-plugin-deployed and others are [mime-]typed/resource-type-plugin-deployed.

** I think I prefer just adding to the Configuration wrapped by the existing ResourceTypeBundleConfiguration to absorb the <content> stuff. As opposed to introducing BundleDestinationDefinition.  It already exists and Configuration is super-flexible for making additions.  Or, perhaps introduce a BundleDestinationDefinition pojo that can be retrieved via ResourceTypeBundleConfiguration (like getDestinationDefinitions()).

** The diagram indicated that the Bundle name is derived from package, is that right?

** Overall I'm still absorbing the proposed changes here. The loss of BundleType for a Bundle is something that makes sense given that the Bundle will already have a mime-type.

* Can we simplify Repo stuff?  Do we really need a Repo-Resource relationship?

* Can we also eliminate all of the Advisory stuff?