This can wait a while, and certainly until after your demo. I'll try to move it to the Wiki so folks can read/contribute as their time allows, and not struggle to decipher (Adam English)/comprehend/respond whilst surviving a day's inbox overload...
regards Adam ----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: "Gump code and data" <[EMAIL PROTECTED]> Sent: Monday, March 01, 2004 7:47 PM Subject: Re: Gump Database > Adam R. B. Jack wrote: > > > Stefano wrote: > > > > > >>While the question that you should be asking yourself is: what does the > >>data look like? how stuctured is it? > >> > >> From where I stand, the gump metadata is highly structured and can be > >>perfectly mapped in to a relational structure with reasonable effort. > >>Also, given its structure, can be indexed precisely and thus queried > >>very efficiently. > > > > > > So the fact that I can visualize this it into a huge rats nest in my head > > (especially when wired into objects) doesn't help me make a case for it > > being unstructured? ;-) ;-) > > > > Ok, I hear you -- and stepping back, looking at the main (named) entities as > > entries in tables, I can see a relational schema with relationships as names > > with or without RI. What I can't see (though) is what helps me with the time > > aspect --- i.e. when a dependency is dropped, what do I compare against? > > nonono wait a second. What are you talking about? I was talking about > putting the historical data into the system, not the gump metadata. > > > I guess the data I'm interested in right now is (somehow) relationships over > > time. One projects relationship to it's repository, to it's peers, to > > communities (of users). How that looks, I'm not sure, but I'll try to answer > > that in my head before I continue. > > I have an email in my draft folder about how we can do perfect nagging > with gump... but I need to understand the graph complexity before I can > go on and I don't have much time ATM since we are delivering the first > demo of our project next week. > > >>At that point, once you have the data in the database, you can start > >>thinking about what to do with it. Dependency graph visualization, > >>history of dependencies, FoG estimation, all of these are problems that > >>will result in particular queries and particular use of the result set. > > > > > > I like XML as the human (community) editable interface, and converting it to > > relational for each run really doesn't appeal to me. > > Of course!! Nonono, I don't want to move from XML descriptors to > relational data, that would be stupid without an GUI or a webapp to > guide people, but I wouldn't use it anyway. > > > Even if I do, comparing > > as I load, and detecting changes -- also sounds like work. It also sounds > > similar to the XML to Object work that Gumpy is doing, and I was hoping > > something could help out here w/o me doing it myself in pedestrian steps. > > I am *NOT* proposing to change the way gump loads metadata but the way > gump stores history information > > > I need to do more thinking, but thanks for the direct feedback, I appreciate > > that. Another persons clarity helps. > > > > BTW: So say we want MySQL [for results and maybe more], how do we set that > > up? Do we install, or leverage an existing MySQL install at Apache? > > good question, but too early now, let's focus on what we want to do and > how, the infrastructural details will come after that. > > -- > Stefano. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
