coapp-developers team mailing list archive

[Eric Schultz <wwahammy@xxxxxxxxx>]

I understand there are different possible keywords i.e.: "Beta", "XML", etc.
I don't understand though why there is a type and value column on the
CO_TAGS table.

On Thu, Aug 12, 2010 at 8:00 PM, Garrett Serack <garretts@xxxxxxxxxxxxx>wrote:

>  Sure. Different Types of keywords (or tags) … could include “Beta”, etc?
>
>
>
>
>
> Yes. Well, sorta. We do require that roles in the same MSI are versioned
> together. Since we anticipate many smaller packages, this won’t be as silly
> as it may sound.
>
>
>
> And, kindof.
>
>
>
> On one hand, by keeping our required data separate, it makes it easier to
> one day abandon MSI (if things came to that). On the other hand, if it’s not
> too hard, why not merge them. I’ll let you make the call.
>
>
>
> Although, platform, don’t trust the MSI version of that… it’s evil.
>
>
>
> G
>
>
>
> *From:* Eric Schultz [mailto:wwahammy@xxxxxxxxx]
> *Sent:* Thursday, August 12, 2010 5:11 PM
> *To:* Garrett Serack
> *Cc:* coapp-developers@xxxxxxxxxxxxxxxxxxx
> *Subject:* Re: Questions, Questions, Questions
>
>
>
> Hey gang,
>
>
>
> One quick question regarding the MSI tables, one little more complex one
>  and some food for thought.
>
>
>
> - On CO_TAGS, I understand that it holds keywords so what is the type
> column there for? Are there different types of keywords?
>
>
>
> - Regarding CO_BINDING_POLICY, as Garrett said this is needed to understand
> which versions of the package this one replaces, particularly for SxS and
> .NET assemblies. To me, that assumes that each package can only contain a
> single assembly. Is that correct?
>
>
>
> - Some of these columns seem to duplicate functionality already implemented
> in Windows Installer. Offhand, display_name, description, architecture,
> author_version and the entire concept of keyword tags have clear analogs in
> built-in MSI tables. Is this intended?
>
>
>
> Eric
>
>
>
>
>
>
>
> On Thu, Aug 12, 2010 at 1:20 PM, Garrett Serack <garretts@xxxxxxxxxxxxx>
> wrote:
>
> Hey Eric,
>
> (you might as well post these to the mailing list so that we can keep track
> of them… and so others can correct me when I’m wr^H^H … mistaken)
>
>
>
>
>
> >> In the CO_PACKAGE table, there is an id field. What type is this field
> supposed to be and where does it come from? (autogen by mkPackage, autogen
> by previous part of CoApp toolchain or set by the developer)
>
>
>
>
>
> >> Are CoApp package IDs globally unique? If I say I want package with ID
> 1, I can be safe knowing no other package from any repo will have that ID?
> Are these the IDs you had mentioned should be generated in a consistent
> manner, say with MD5 hashes of name, version, architecture and I assume the
> developer's public key?
>
>
>
> I think ID was intended to be a GUID generated as an MD5 of the {name +
> arch + version + publickeytoken}. Let’s go with that assumption right now.
>
>
>
>
>
> >>How does name and display_name differ?
>
>
>
> Display name I believe was cosmetic in nature so possibly “Mozilla Firefox”
> whereas the name would just be “firefox” .
>
>
>
> >>What is author_version in CO_PACKAGE_PROPERTY and how is that different
> from version in CO_PACKAGE?
>
>
>
> Author version may be slightly different due to the way the original
> project names their versioning OpenSSL for example has stuff like 0.98k …
> whereas our versions must be <num>.<num>.<num>.<num> where each num is
> 0-65535… This is dictated by the way .NET and WinSxS assemblies are
> versioned.
>
>
>
> >> -What does CO_URL correspond to and what goes in 'type'?
>
>
>
> There are several URLs associated with things… package location, original
> project page, Launchpad page, that type of thing. Type is just the type of
> URL—I suppose we should have a canonical list of what types we use.
>
>
>
> >> - Do CO_ROLE, CO_TAG and CO_BINDING_POLICY actually get their
> FK_package_id's from CO_PACKAGE_PROPERTIES? That's what the diagram shows
> but it doesn't really make sense to me why that'd be. :)
>
>
>
> The FK_package_id is the foreign key for the package id… which is simply
> the ID field in the CO_PACKAGE table.
>
> FK_role_id is just the ID of the CO_ROLE table.
>
>
>
>
>
> >> - Do we just allow any string into CO_ROLE flavor or does it have to be
> one of the ones we've already come up with like "debugging" and "pgo"?
>
>
>
>
>
> Yeah, flavor is pretty flexible. It’s wide open at this point.
>
>
>
> >> Can there be multiple roles of the same type but different flavor in a
> package? Also can flavor be null?
>
>
>
> Hmmm. Yes, it can be null. I suppose that multiple flavors can be in the
> same package. Not entirely sure that’s thought out all the way tho.
>
>
>
> >> - What is the type column of CO_LICENSE for?
>
>
>
> I’m … not… sure…
>
>
>
> >> - What does CO_BINDING_POLICY do?
>
>
>
> Ah, this allows us to say what this package supersedes.  (this is a concept
> from WinSxS) – we can say that version “1.1.150.77” is a replacement for
> versions “1.1.0.0” to “1.1.150.76”
>
>
>
> >> - What does CO_TAG and its columns hold? Keywords or some sort?
>
> Yeah, just for keyword tagging: “editor” “browser”, etc…
>
>
>
> >> - Is CO_DEPENDENCY id a GUID or sequentially created int? Same with
> CO_ROLE id and CO_URL id.
>
>
>
> Let’s assume GUID. I think.
>
>
>
> >> - Is there a need for CO_DEPENDENCY to have an FK_package_child_id?
> Won't that always be the package id in a given msi?
>
>
>
> You are probably correct.
>
>
>
> >> - CO_INSTALL_PROPERTIES: You're going to have to totally explain it cuz
> I've got no idea :)
>
>
>
> At this point in time, this is just the list of symbolic links that the
> engine creates at the end of installation.  It’s going to be more
> complicated in the future, but for now assume that’s all this is.
>
>
>
> Enjoy your Thursday morning :)
>
>
>
> Eric
>
>
>
> *Garrett* *Serack* | Open Source Software Developer | *Microsoft
> Corporation *
>
> *I don't make the software you use; I make the software you use better on
> Windows.*
>
>
>
>
>
>
>