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 <garre...@microsoft.com>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:wwaha...@gmail.com] > *Sent:* Thursday, August 12, 2010 5:11 PM > *To:* Garrett Serack > *Cc:* coapp-developers@lists.launchpad.net > *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 <garre...@microsoft.com> > 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.* > > > > > > >
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
