15:02:48 <pilhuhn> #startmeeting
15:02:48 <jbott> Meeting started Tue Jun 14 15:02:48 2011 UTC.  The chair is pilhuhn. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:48 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:03:01 <pilhuhn> Welcome to this meeting about dependent values and linking.
15:03:02 <pilhuhn> The related wiki page is
15:03:02 <pilhuhn> http://rhq-project.org/display/RHQ/Needed+-+dependent+properties+and+linking
15:03:02 <pilhuhn> #topic introduction
15:03:13 <pilhuhn> The upper half shows some screen shots of what is meant here.
15:03:21 <pilhuhn> We have discussed this already in the previous meeting (see http://people.redhat.com/~manderse/irc.freenode.org/meetings/rhq/2011/rhq.2011-05-31-15.02.html )
15:03:43 <pilhuhn> The upper half of the wiki page shows some screen shots of what is meant here.
15:03:43 <pilhuhn> Especially the dependent values are needed for the AS7 plugin, as there are many properties when setting up new resources that need to come from other parts of the as7 management model, which is represented in RHQ as resources (and configuration entries).
15:03:58 <pilhuhn> Linking would allow to click on configuration properties in view mode and then end up at the target resource/config property that did define the value.
15:03:58 <pilhuhn> Priority is clearly on the dependent values
15:05:09 <pilhuhn> Questions so far?
15:05:23 <mazz> is this all to support the UI?
15:05:29 <pilhuhn> yes
15:05:50 <pilhuhn> I think it will get clearer now:
15:05:51 <pilhuhn> #topic use cases
15:05:51 <pilhuhn> Below the intros are some use cases at
15:05:51 <pilhuhn> http://rhq-project.org/display/RHQ/Needed+-+dependent+properties+and+linking#Needed-dependentpropertiesandlinking-Usecases
15:06:18 <ccrouch> pilhuhn: so Linking depends on Dependent Values
15:06:20 <ccrouch> ?
15:07:02 <ccrouch> or perhaps this is better
15:07:07 <pilhuhn> yes, sort of. As I currently only see the dependent values as possible link targets - for those, we know where to point to. We don't know that for arbitrary values
15:07:16 <ccrouch> Linking requires Dependent Values?
15:07:24 <ccrouch> right
15:07:26 <ccrouch> gotya
15:07:58 <pilhuhn> There is one interesting question here is (see UC "Add a new web connector")
15:07:58 <pilhuhn> If a new config has two properties A and B, which are both defined elsewhere and thus candidates for dependent values AND the values of B can be determined/narrowed after A has been selected:
15:07:58 <pilhuhn> do we need to make B depending on A as well? This for sure makes the implementation more complicated, but of course would make a lot of sense to end users.
15:08:08 <ccrouch> #idea a third option could be "Validation"
15:08:15 <pilhuhn> I've also forwarded this question to Alan, who can't make it today
15:08:33 <pilhuhn> ccrouch what do you mean here?
15:08:39 <ccrouch> so the user is allowed to whatever they like in the text box, and the plugin validates whether it matches something it knows about
15:08:56 <ccrouch> ...allowed to *enter* whatever.....
15:09:18 <ccrouch> less useful, obviously, but maybe less work too
15:09:48 <pilhuhn> Actually for the dependent values I think it is not that complicated if one is a GWT guy :)
15:10:12 <ccrouch> ok, we'll see what the GWT folks have to say :-)
15:10:17 <ccrouch> please carry on
15:10:31 <pilhuhn> any more questions so far?
15:11:08 <pilhuhn> #topic Design idea
15:11:08 <pilhuhn> See also http://rhq-project.org/display/RHQ/Needed+-+dependent+properties+and+linking#Needed-dependentpropertiesandlinking-Designidea
15:11:08 <pilhuhn> Basically the plugin descriptor defines a new element <c:source> that says "this is a dependent value" (the exact expression synatax is TBD).
15:11:08 <pilhuhn> This is parsed and persisted in the server. Now when the UI wants to display that property, it calls back into the server to resolve that expression, which delivers a list of PropertyDefinitionEnumeration, that the UI displays like it does today with the <c:option> elements.
15:13:00 <pilhuhn> I am not yet completely sure what to put into the property for the linking, but I think it would go a very similar way. If a property is marked as dependent value, the callback would resolve the link target like Resource#12345 and the UI can then use its usual way to create hyperlinks
15:13:35 <mazz> just as long as the server does not return "Resource#12345"
15:14:03 <mazz> its up to the UI to determine that the target looks like. the server should just return something like a Resource entity or some thing like it
15:14:04 <ccrouch> pilhuhn: one nice thing seems to be that this can all be kept serverside
15:14:16 <pilhuhn> I was thinking a <c:property-simple> can have either <c:options> or <c:source>, but jshaughn was thinking that both could make sense
15:14:18 <ccrouch> i.e. no calls out to the agent
15:14:51 <pilhuhn> mazz yes I did not mean x#y literally - just as "this is a resource with id x"
15:14:55 <pilhuhn> ccrouch no
15:15:04 <pilhuhn> ccrouch only dependent values that we have in inventory
15:15:26 <ccrouch> gwt folks: so how realistic are the changes described in http://rhq-project.org/display/RHQ/Needed+-+dependent+properties+and+linking#Needed-dependentpropertiesandlinking-Thingstocheckout
15:15:51 <pilhuhn> Perhaps I was thinking too much in AS7 terms here, but for the AS7 usecase we only want to consider things we have in inventory already
15:16:18 <lkrejci> ccrouch: but our current way is "when editing, we use the live configs" whereas these dependent values would come from the last known state
15:16:41 <pilhuhn> ccrouch actually I did investigate this. And I can get the callback from onDraw() into the ConfigManagerBean.
15:16:57 <pilhuhn> #topic implementation details
15:16:57 <pilhuhn> The wiki page already lists a BOM as lsit of items that need to be modified for dependent values.
15:17:21 <pilhuhn> There are a few places to hook that in
15:17:38 <pilhuhn> org.rhq.enterprise.gui.coregui.client.components.configuration.ConfigurationEditor#buildSimpleField could be a good place as the simple properties are already unrolled
15:17:38 <pilhuhn> .oO( Did I mention that I want Closures for this recursive property handling? )
15:17:38 <pilhuhn> But then, as Jay wrote in the email thread
15:17:38 <pilhuhn> #link https://fedorahosted.org/pipermail/rhq-devel/2011-June/000880.html that this might result in too many callbacks into the server.
15:17:50 <pilhuhn> Perhaps adding this additional call to the end of ConfigurationEditor.onDraw() could make sense - but then we are always calling back - even if the configuration has no such dynamic values at all.
15:18:10 <pilhuhn> lkrejci I don't see this as issue (for the AS7 use case)
15:18:15 <mazz> the config editor can examine the defs
15:18:24 <mazz> if the config editor sees at least one thing is dynamic, it can reload it
15:18:31 <mazz> you don't need a special piece of metadata in Configuraiton
15:18:35 <ccrouch> (10:16:16 AM) lkrejci: ccrouch: but our current way is "when editing, we use the live configs" whereas these dependent values would come from the last known state
15:18:35 <ccrouch> good point
15:18:50 <mazz> the editor itself can determine this by just looking at the def and if it sees something is dynamic, to know it needs to reload
15:19:09 <pilhuhn> mazz that "marker" is deep down in the config, probably nested many levels deep in a list of maps of maps of simple property
15:19:18 <ccrouch> ips: config editor guru :-), thoughts ^
15:19:21 <jshaughn> i think either the config editor fills in as it parses the def (i think this is what mazz is saying above) or a single call to the server to "realized" the entire confg def up front
15:19:49 <mazz> its not that hard to scan these defs.. our defs are so large and so hierarchically deep that it would be inefficient to do this
15:19:54 <pilhuhn> jshaughn that are the options that I mean - the one is in buildSimpleField, where stuff is "unrolled"
15:19:58 <mazz> or defs are NOT so large, I should say
15:20:39 <jshaughn> the slsb calls should probably not be tied to onDraw and stuff like that
15:20:40 <pilhuhn> the other early on in doDraw()
15:20:54 <mazz> its not like we have these enormously complex defs . it could be fast to scan it to find dynamic pieces
15:21:24 <pilhuhn> I mean - if we know how we do it , I can code up the server side up to ConfigManagerLocal and then some GWT person "just hooks it in"
15:21:40 <pilhuhn> mazz No, they are not that deep, you are right.
15:22:14 <pilhuhn> It is just that we write that config unrolling code hundreds of time all over the place - with all the possible error situatuions
15:22:30 <pilhuhn> .oO( Did I mention closures ?)
15:23:16 <pilhuhn> jshaughn where would you put it?
15:24:29 <ccrouch> argh, ips is sick today
15:24:58 <pilhuhn> yep :-/
15:25:03 <ccrouch> #action ips needs to review this
15:25:56 <lkrejci> what about collecting the requests while parsing the def (we must be already doing that ?) and then once the parsing / drawing is done, fire off one async call to the server and only "enable" the props in question in the handler of that callback?
15:26:32 <pilhuhn> lkrejci you should have put a #idea in front - does not sound bad.
15:26:47 <lkrejci> #idea ^^ :)
15:26:53 <pilhuhn> But then just doing that server side for each config definition is not too heavyweight
15:27:02 <pilhuhn> lkrejci that does not really work for the minutes
15:27:10 <lkrejci> oops
15:27:18 <lkrejci> didn't realize that
15:27:24 <pilhuhn> There is one thing still left open, for which we don't need ips right now:
15:27:40 <pilhuhn> #topic the expression language.
15:28:14 <pilhuhn> For the wiki page I did just invent something to illustrate the case , but I think we should use a language that the plugin writer may already know
15:28:18 <pilhuhn> - xpath
15:28:25 <pilhuhn> - DynaSearch expression
15:28:34 <pilhuhn> - DynaGroup expressions
15:28:46 <pilhuhn> afaik the latter two are not compatible
15:28:51 <jshaughn> we could just flag config defs with dynamic values witha boolean, and the config editor could make a single, up front async call to realize the entire config def. then proceed as it does today
15:29:39 <jshaughn> as for the expression language that's a ? for me.  I really don't think we want another expression language to result from this feature need.
15:29:48 <ccrouch> we'd need to have this support groups too right?
15:30:06 <ccrouch> for configuring multiple resources at the same time?
15:30:35 <pilhuhn> ccrouch that is groups as start point - the ConfigurationEditor supports that
15:30:47 <jshaughn> ccrouch:does that impact anything?  it's still a single config def, right?
15:31:25 <ccrouch> jshaughn: i have no idea :-), i just wanted to make sure we thought of it
15:31:27 <pilhuhn> ccrouch group as target is good globally , but from what I can tell so far not needed for the as7 use cases
15:32:26 <pilhuhn> #action document this, pilhuhn: use case: have a mod_cluster plugin and let it pick either single AS as targets or a group of AS
15:32:37 <pilhuhn> Yep, that would make sense
15:33:25 <pilhuhn> jshaughn I meant the Dyna* are not compatible with each other. I did not mean "not compatible with this feature"
15:34:01 <pilhuhn> I guess DynaSearch would make sense, as there is (?) a direct translator into criteria queries available
15:34:16 <jshaughn> it would be really nice if we didn't have to deal with onther expression language.  any way to somehow use a CLI script fragment in the plugin descriptor?  Or (far out idea) how about requiring a server plugin and somehow just specifying a tag that would hitup some canned SS code.
15:35:08 <pilhuhn> SS?
15:35:20 <jshaughn> server-side
15:35:35 <pilhuhn> cli script to do the resolving?
15:36:07 <jshaughn> dyna-search, perhaps that could work
15:36:21 <jshaughn> or just the search syntax like in the search bar
15:36:26 <lkrejci> -1 for CLI scripts - they're quite chatty and too heavy for what we need to do here, imho
15:36:35 <pilhuhn> lkrejci I think so as well
15:36:37 <jshaughn> yeah, I didn't like that idea either
15:36:47 <pilhuhn> jshaughn isn't DynaSearch == SearchBar?
15:36:55 <jshaughn> pilhuhn: is probably on target with the [dyna]search syntax
15:37:31 <pilhuhn> #action investigate DynaSearch as expression language
15:38:01 <jshaughn> pilhuhn: honestly not sure. maybe it's a subset. we don't really need the grouping/pivoting here (or in the search bar)
15:38:24 <pilhuhn> ah ok . Yes I agree
15:39:44 <pilhuhn> jshaughn Back to flagging the config object itself -- do you think it is worth the effort, as this would mean to change the domain object for the config object itself.
15:39:55 <pilhuhn> which enlarges the footprint of changes
15:39:56 <ccrouch> right DynaGroup syntax != Search
15:40:08 <pilhuhn> ccrouch DynaSearch :)
15:40:18 <ccrouch> != that either :-)
15:40:32 * pilhuhn is confused
15:40:34 <pilhuhn> :)
15:40:59 <pilhuhn> Ok, next steps:
15:41:04 <ccrouch> (10:36:45 AM) pilhuhn: jshaughn isn't DynaSearch == SearchBar?
15:41:04 <ccrouch> i thought this was true
15:41:13 <jshaughn> pilhuhn: not sure, just an idea.  easier to probaby just do a preview parse and look for dynamic bits
15:41:16 <mazz> we should not change the Config object, no
15:41:35 <mazz> I do not see it as necessary AND, as you said, has the potential to affect a lot of things
15:42:09 <pilhuhn> #agreed no additional flag in ConfigDefinition object
15:42:26 <jshaughn> we could easily determine if we need to resolve anytig dynamic in a simple up-front parse
15:42:55 <pilhuhn> #action pilhuhn to flesh out config xsd and parsing of it + persisting of <c:source/> entries
15:43:18 <jshaughn> i think i'd favor a single server-call to resolve all the dynamic parts in one call. return the fully realized config def, and then let the confog editor proceed as it does today
15:43:37 <pilhuhn> jshaughn Yes, I think so too
15:45:14 <pilhuhn> #help jshaughn would you help ConfigEditor side on this?
15:45:46 <jshaughn> it can be a bit of a pain to have async calls in the onInit of something (like the config editor) but it's doable.
15:45:51 <ccrouch> so before we start implementing this, have we got an estimate for how long it will take? and whether we can do this and complete the rest of the core as7 plugin?
15:46:19 <pilhuhn> ccrouch The core/ stuff should be done in 2 days
15:46:57 <pilhuhn> ccrouch There is stuff in the as7 plugin that would benefit a huge deal from dependent values being present, as otherwise input of data is much to error prone
15:47:25 <ccrouch> understood. we wouldnt be looking at it, if it wasnt important :-)
15:47:33 <pilhuhn> That is why I suspended work on the plugin and started this feature
15:47:47 <ccrouch> i just want to get an idea of the level of effort
15:48:29 <ccrouch> #action pilhuhn to estimate level of effort
15:50:00 <pilhuhn> Ok will do. I can't estimate the UI side -- my feeling tells me 20mins for ips or jshaughn  and 5 days for me
15:51:05 <pilhuhn> The idea really is to leave the ConfigEditor as most as possible "as is" and just pass an "augemented" definition to it (or better have it pull it)
15:51:17 <pilhuhn> any more questions?
15:52:34 <pilhuhn> Going 1
15:52:38 <pilhuhn> 2
15:52:42 <pilhuhn> 2.5
15:52:43 <ccrouch> #action jshaughn/mazz/ips to estimate the ui side
15:52:52 <pilhuhn> 3
15:53:02 <pilhuhn> #endmeeting