<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    Lukas,<br>
    <br>
    (note: I wrote most of this before the presentation last Friday, so
    some of it is answered or dated.&nbsp; Just posting it to get the thread
    moving... -Jay)<br>
    <br>
    Looking at the latest revision of the wiki. The design is
    progressing well.&nbsp; 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.&nbsp;
    A couple of questions/comments:<br>
    <br>
    * The move to Repo-based content authz seems like a good idea that
    will map well to the current Group-based resource authz.&nbsp; And
    therefore should be easily adapted/understood by users (and us).<br>
    <br>
    * I'm a little confused by the unique constraint on
    (Package.name,Repo) where Package-Repo is ManyToMany.&nbsp; That would
    mean I could have different distinct Packages with the same name, in
    different repos.&nbsp; But I could also have the same Package in
    different Repos.&nbsp; 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?&nbsp;&nbsp; This does prevent two different test.war apps in the
    same repo, which may make sense, but actually maybe it's too
    restrictive.<br>
    <br>
    Keeping this ManyToMany is probably a good idea as it is analogous
    to the Resource-Group relationship wrt Repo-based authz.&nbsp; But then
    you may need to keep and re-purpose Package.classification as
    something that can further identify a Package.&nbsp; Name may not be
    enough.&nbsp; The same is true of resources, to identify a resource you
    can't go by name, the "classifier" is ancestry.<br>
    <br>
    * +1 to removal of ContentSource, we'll need to work out the details
    of the CSP feature<br>
    * +1 to removal of PackageCategory<br>
    * +1 to deprecation/removal of PackageType<br>
    <br>
    * With respect to the PackageVersion changes: <br>
    **&nbsp; +1 to removing architecture.&nbsp; Does this mean we can also kill
    off the rhq_architecture table?<br>
    ** I get why you don't want displayName.&nbsp; 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.<br>
    ** +1 to removing displayVersion, not sure I see a reason for this,
    either.<br>
    ** +1 to removing MD5 if we can.&nbsp;&nbsp; Maybe it was the only digest we
    could get for certain remote content?&nbsp; I don't know.<br>
    ** license_name, license_version?&nbsp; These aren't mentioned, can we
    get rid of them?<br>
    <br>
    * Mime types:<br>
    ** +1 to the approach, I think this will be very good as the
    underlying mechanism for moving the model forward.<br>
    ** 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?&nbsp; Is this going to be true?&nbsp; Maybe
    it is , I'm just asking.<br>
    <br>
    * With respect to Content discovery, you say: "<span style="color:
      rgb(51, 51, 51); font-family: Arial, Helvetica, FreeSans,
      sans-serif; font-size: 13px; font-style: normal; font-variant:
      normal; font-weight: normal; letter-spacing: normal; line-height:
      17.328125px; orphans: 2; text-align: left; text-indent: 0px;
      text-transform: none; white-space: normal; widows: 2;
      word-spacing: 0px; -webkit-text-size-adjust: auto;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none;">...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".&nbsp; </span><span style="color: rgb(51, 51,
      51); font-family: Arial, Helvetica, FreeSans, sans-serif;
      font-size: 13px; font-style: normal; font-variant: normal;
      font-weight: normal; letter-spacing: normal; line-height:
      17.328125px; orphans: 2; text-align: left; text-indent: 0px;
      text-transform: none; white-space: normal; widows: 2;
      word-spacing: 0px; -webkit-text-size-adjust: auto;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none;">This content
      without a Repo, what is it "attached" to?&nbsp; How is it
      tracked/removed/accessed?</span><br>
    <br>
    * Bundle Consequences:<br>
    * We need better terminology for "normal bundle" and "content
    bundle".&nbsp; 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.<br>
    <br>
    ** I think I prefer just adding to the Configuration wrapped by the
    existing ResourceTypeBundleConfiguration to absorb the
    &lt;content&gt; stuff. As opposed to introducing
    BundleDestinationDefinition.&nbsp; It already exists and Configuration is
    super-flexible for making additions.&nbsp; Or, perhaps introduce a
    BundleDestinationDefinition pojo that can be retrieved via
    ResourceTypeBundleConfiguration (like getDestinationDefinitions()).<br>
    <br>
    ** The diagram indicated that the Bundle name is derived from
    package, is that right?<br>
    <br>
    ** 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.<br>
    <br>
    <span style="color: rgb(51, 51, 51); font-family: Arial, Helvetica,
      FreeSans, sans-serif; font-size: 13px; font-style: normal;
      font-variant: normal; font-weight: normal; letter-spacing: normal;
      line-height: 17.328125px; orphans: 2; text-align: left;
      text-indent: 0px; text-transform: none; white-space: normal;
      widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none;"></span>* Can we
    simplify Repo stuff?&nbsp; Do we really need a Repo-Resource
    relationship?<br>
    <br>
    * Can we also eliminate all of the Advisory stuff?<br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>