On Tue, Apr 14, 2009 at 11:50 PM, Ethan Mallove wrote:
> On Tue, Apr/14/2009 09:27:14PM, Mike Dubman wrote:
> >On Tue, Apr 14, 2009 at 5:04 PM, Jeff Squyres
> wrote:
> >
> > On Apr 13, 2009, at 2:08 PM, Mike Dubman wrote:
> >
> >Hello Ethan,
> >
> > Sorry for joining the di
On Wed, Apr 15, 2009 at 3:51 AM, Jeff Squyres wrote:
> On Apr 14, 2009, at 2:27 PM, Mike Dubman wrote:
>
> Ah, good point (python/java not perl). But I think that
>> lib/MTT/Reporter/GoogleDataStore.pm could still be a good thing -- we have
>> invested a lot of time/effort into getting our parti
On Apr 15, 2009, at 9:14 AM, Mike Dubman wrote:
Hmm. Ok, so you're saying that we define a "phase object" (for each
phase) with all the fields that we expect to have, but if we need
to, we can create fields on the fly, and google will just "do the
right thing" and associate *all* the data
On Wed, Apr 15, 2009 at 5:23 PM, Jeff Squyres wrote:
> On Apr 15, 2009, at 9:14 AM, Mike Dubman wrote:
>
> Hmm. Ok, so you're saying that we define a "phase object" (for each
>> phase) with all the fields that we expect to have, but if we need to, we can
>> create fields on the fly, and google
On Apr 15, 2009, at 1:45 PM, Mike Dubman wrote:
yep. correct. We can define only static attributes (which we know
for sure should present in every object of given type and leave
phase specific attributes to stay dynamic)
Hmm. I would think that even in each phase, we have a bunch of
fiel
On Wed, Apr 15, 2009 at 8:50 PM, Jeff Squyres wrote:
> On Apr 15, 2009, at 1:45 PM, Mike Dubman wrote:
>
> yep. correct. We can define only static attributes (which we know for sure
>> should present in every object of given type and leave phase specific
>> attributes to stay dynamic)
>>
>> Hmm.
I have been listening in on the thread, but have not had time to
really look at much (which is why I have not been replying). I'm
interested in listening in on the teleconf as well, though if I become
a blocker for finding a time feel free to cut me out.
Best,
Josh
On Apr 14, 2009, at 8:51
