17:00:54 <mazz> #startmeeting
17:00:54 <jbott> Meeting started Thu May 26 17:00:54 2011 UTC.  The chair is mazz. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:54 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:01:13 <mazz> ok, the wiki page that we are going to go over is here:
17:01:14 <mazz> http://rhq-project.org/display/RHQ/Design-BundleDeploymentToNonPlatforms
17:01:29 <mazz> the first question we need to get out of the way is this:
17:01:35 <mazz> "Is This A Good Idea?" :-)
17:01:46 <mazz> I have no come up with a defeater to say we should not do this.
17:02:06 <mazz> does anyone have any comments/concerns about implementing this? is does involve some big conceptual changes
17:02:42 <mazz> (I'll normally let 60s of silence before continuing)
17:02:49 <ccrouch> so why i think we should do it: because it helps usability of Bundles tremendously for doing app deployments
17:03:00 <jsanda> i've only looked at it briefly, but i think it is a great idea
17:03:14 <jsanda> i honestly thought bundles already supported app deployment
17:03:30 <mazz> my concern (and I think jshaughn's as well) was it adds more complexity to the idea of bundles
17:03:32 <ccrouch> jsanda: it does
17:03:44 <David-UP> In the case of deploying to container (JBoss, Tomcat) it may actually make more intuitive sense.
17:03:45 <mazz> before it was simple - you install a package of bits to a platform's file system
17:03:48 <ccrouch> mazz: from a user perspective its less complex
17:03:50 <jsanda> but not deploying an ear/war to a jboss server right?
17:04:07 <jsanda> or am i misunderstanding
17:04:11 <ccrouch> David-UP: exactly
17:04:25 <mazz> ok, I'm perfectly willing to say my thought on this was counterintuitive. I thought more complex, everyone says less complex. I therefore stand corrected :)
17:04:32 <ccrouch> jsanda: ear/wars are possible, you just had to be careful
17:04:51 <ccrouch> mazz: well explain why its more complex :-)
17:05:21 <mazz> ok, well, as it is now, I think bundles concept (with bundle versions, destinations, deployments and the UI that shows all that) is complex
17:05:30 <David-UP> We use for both stand-alone JVM or Native (c/c++) and then Containers.  Maintaining current platform deployment makes sense for stand alone JVM native apps, but makes sense to deploy to server resources for those
17:05:35 <mazz> but underneath it all is "put these bits somewhere under "/" directory"
17:05:37 <ccrouch> i was expecting the same principle to apply, about pushing stuff to a file location, but now you can let other parts of the system supply that location, rather than having the user manually supply it
17:06:00 <David-UP> YEs
17:06:16 <mazz> ccrouch: David-UP: yes, in fact, that wiki I wrote tries to maintain as much as that as possible
17:06:24 <mazz> but now consider we are relating non-platforms to bundles
17:06:31 <mazz> so... do we have a new "bundle" tab for all resources?
17:06:51 <ccrouch> (12:05:20 PM) mazz: ok, well, as it is now, I think bundles concept (with bundle versions, destinations, deployments and the UI that shows all that) is complex
17:06:51 <ccrouch> thats fair, but its a fairly complex problem, and the changes being suggested should make the situation worse
17:07:07 <mazz> should NOT I hope you meant :)
17:07:18 <ccrouch> (12:06:30 PM) mazz: so... do we have a new "bundle" tab for all resources?
17:07:18 <ccrouch> huh? we dont even have a bundle tab for platforms?
17:07:26 <ccrouch> thats an orthogonal issue
17:07:35 <ips> ccrouch: no, we talked about it, but never got around to doing it
17:07:50 <ccrouch> (12:07:05 PM) mazz: should NOT I hope you meant
17:07:50 <ccrouch> doh! yes :-)
17:07:53 <mazz> ccrouch: no! all Bundle related stuff is under the Bundle main section of the UI (except for that little portlet on the Summary tab)
17:08:02 <ccrouch> ips: right, thats fine, separate issue
17:08:17 <ccrouch> sorry
17:08:37 <ccrouch> i can see how my sentence could have been misinterpreted
17:08:49 <ccrouch> i luv irc
17:08:51 <jsanda> we're going to be doing something very similar with the new snapshot face where we ask resources for a file system location. i wonder if things could be generalized a bit to at least to have a single facet
17:08:53 <ccrouch> so..
17:08:57 <David-UP> I think you are still "technically" deploying to the underlying platform (aka, copying files to a filesystem), but abstracting it out to give the user the impression you are deploying to a container, with the added step you may be invoking the containers deploy mechanism after the copy
17:09:29 <ccrouch> what i'm saying is: right now we dont have a bundle tab for platforms, so why should we even think about introducing one for anything else
17:09:35 <David-UP> Still have to access the platformt he resourse lives inside
17:09:45 <ccrouch> i was replying to (12:06:30 PM) mazz: so... do we have a new "bundle" tab for all resources?
17:09:50 <mazz> ccrouch: I see what you are saying now.
17:10:23 <ccrouch> sorry for the confusion, i know we dont have a bundle tab on platforms :-)
17:10:34 <mazz> jsanda: my wiki mentions this, but to be clear, I don't think right now I'm advocating a new plugin facet to support this. IMO, we can do all of this without asking the plugin developer to do anything other than adding a <bundle-target> element to the descriptor XML
17:10:54 <jsanda> ok, cool
17:10:56 <mazz> I do mention the possibility of a facet, but I don't think its is necessary
17:11:04 <ccrouch> David-UP: agreed
17:11:13 <jsanda> mazz: yeah, makes sense
17:11:19 <David-UP> This all sounds good to me,,,,
17:11:23 <mazz> David-UP: so can I assume you are using bundles feature today?
17:11:30 <David-UP> Yes we are
17:12:10 <mazz> what is your opinion/thoughts on the fact that bundles are technically not related to any underlying resources.
17:12:11 <David-UP> mazz: yes we are (will try to remember to do that!)
17:12:32 <mazz> for example, you could have a JBossAS bundle deployed, but that bundle isn't related to the JBossAS rsource that is going to be discovered by the agent
17:12:43 <ips> mazz - would we want some new metadata in a bundle def to say which type of resources it targets?
17:12:59 <ccrouch> mazz: my 2c, this is a completely separate question from the one we planned to discuss on this call :-)
17:13:17 <David-UP> mazz: It's more a conceptual thing.  For standalone JVM deployment deploying to platform make intuitive sense, but not so to a container (resource).
17:13:27 <ips> this would allow the gui to be smarter and not allow users to deploy a jboss-eap bundle to an existing jboss eap server's deploy dir say
17:13:30 <mazz> ccrouch: well, this "relating bundles to resources" gets to the notion that we are now relating a BUNDLE to a RESOURCE
17:13:36 <mazz> even though that bundle is probabyl deploying a child resource
17:13:52 <mazz> how deep does this new feature go with adding relationships to resources?
17:14:15 <David-UP> ips: Yes, a filter to say not deploy an .ear (a JBoss Enterprise Archive) to say a Tomcat resource
17:14:49 <David-UP> Or a .jar (executable archive) to a container resource
17:15:25 <ips> right, something like <bundle targetResourceTypes="JBossAS:JBossAS Server,JBossAS5:JBossAS Server" .../>
17:15:27 <mazz> we might be able to add a "resourceType" attribute to the Ant recipe XML somewhere which would add an extra piece of metadata to the  BundleVersion indicating what type of resource it can be deployed to
17:15:42 <ips> that might go in a bundle that deploys an EAR
17:15:50 <mazz> yeah.
17:15:56 <mazz> that might be possible
17:16:01 <mazz> lemme add that to the wiki
17:16:03 <mazz> good suggestion
17:17:25 <ips> it would be cool if after a bundle deploy completes, the plugin container automatically kicked off a scan for new child resources under the target resource (e.g. so the ear that was just deployed as a bundle gets discovered)
17:17:59 <mazz> we might already kick off a scan during normal bundle deployment today, but I'm not sure
17:18:10 <mazz> ok, added http://rhq-project.org/display/RHQ/Design-BundleDeploymentToNonPlatforms#Design-BundleDeploymentToNonPlatforms-AdditionalRecipeMetadata
17:18:17 <David-UP> This would simplify our environement manage a good deal.  Very large environment, where actually manage Jboss instances as if they were in WebLogic style domains and clusters. We have to create resource groups in JON to manage that, but also these other "platform" groups to support the bundle deploys.
17:18:54 <mazz> ok, now, as for how we expose this in the UI
17:18:59 <David-UP> ips: yes, I have to do that via a post-processing script today.
17:19:12 <ips> also, i know this is a somewhat separate feature, but i think we should eventually detect if a Resource was deployed via a bundle and indicate it in the gui
17:19:27 <mazz> ips: that is what I was talking about earlier
17:19:29 <David-UP> ips: absolutely!
17:19:42 <mazz> that ccrouch said didn't think was part of the discussion :}
17:19:51 <mazz> and what I was asking how much of a problem is that today
17:20:13 <David-UP> mazz: its a nuisance...
17:20:43 <mazz> David-UP: if this new feature goes in, does this nuisance get somewhat alleviated?
17:20:44 <ips> so for the bundle-deployed ear, when you go the corresponding EAR resource in the gui (once it's been discovered), you'd see something like: Source Bundle: name: Petstore EAR    version: 2.0
17:20:50 <ips> in the resource summary area
17:21:21 <mazz> right, well, we in the dev team know how hard it will be to actually figure out how to do that :)
17:21:46 <David-UP> ips:  sounds about right to me....nice to see the version "tag" show up, too...
17:21:47 <mazz> so my question is - is this a really BAD problem? or a nuisance that is annoying but not such a problem as to hate this stuff?
17:22:25 <mazz> because to do this would IMO take a long time - if we are going to commit to it, we need to make sure its really needed
17:23:17 <David-UP> mazz:  was a nuisance because we had to do something extra, on our part, to get the deployed resource to show up, external to the actual deployment process.  We have that now, so no big deal for us
17:23:44 <mazz> ok, so back to how we show this new feature in the UI
17:23:56 <mazz> as I understand it, its nothing more than you create a group of non-platforms
17:24:02 <mazz> and select that group in the deployment wizard
17:24:07 <mazz> is there anything else here that I am missing?
17:25:47 <mazz> ok, so we just need to define a group with no additional UI requirements
17:26:30 <mazz> the wiki shows the new agent plugin XML that would be needed. right now its just the piece of data that tells us where the bundle files will be deployed
17:26:32 <ccrouch> so i just lost a bunch of the conversation :-(
17:26:32 <ccrouch> can someone pastebin the last 10mins?
17:26:53 <mazz> ccrouch: we are recording this via jbot -- we'll have a transscript
17:27:35 <mazz> here's one problem that I know some thought of
17:27:47 <mazz> in the case of JBossAS
17:27:51 <David-UP> mazz:  you guys are getting into the implementation details here now, so I will assume with my limited knowledge of that, it that sounds about right to me...
17:28:04 <mazz> I could deploy apps to deploy/
17:28:15 <mazz> or I might want to deploy a patch to my core JBossAS
17:28:24 <mazz> such as jar files to the lib/ directory or bin/ directory
17:29:05 <mazz> we could have the "base dir" for the bundle target as the jboss install directory (e.g. /opt/jbossas)
17:29:11 <mazz> that would allow us to do both
17:29:26 <ccrouch> mazz: that wouldnt work
17:29:29 <mazz> if our base dir is only pointing down to the deploy/ dierctory (e.g. /opt/jbossas/default/deploy)
17:29:41 <ips> mazz - that's asusming the config dir is under the base dir
17:29:41 <mazz> then we can't patch the core server, we can only deploy apps to it
17:29:44 <David-UP> mazz: hmmm....patching the container via this mechanism?  That might be a bit out of scope for now....  But could eventually be a good patch implementation process since most people do not use the "out-of-the-box" RPMs for JON.
17:29:58 <ccrouch> i have a group of two servers, default1 and default2 and want to deploy an app
17:30:03 <mazz> David-UP: that's why I am bringing this up
17:30:12 <mazz> I see this as a potential patch mechanism
17:30:14 <ccrouch> i create a group of those two servers
17:30:16 <mazz> than just an app deploy mech.
17:30:28 <David-UP> mazz:  good topic, glad you did
17:31:01 <ccrouch> if base dir is /opt/jbossas, when I'm deploying I need to specify a different dir for each instance: ./default1/deploy and ./default2/deploy
17:31:11 <ips> mazz - yeah, it could even eventually replace the current jboss CP install mechanism
17:31:14 <mazz> ccrouch: yup - that is a problem
17:31:24 <mazz> ips:  :) which is exactly what I was thinking
17:31:35 <mazz> ccrouch: my solution is thus:
17:31:58 <mazz> <bundle-target>
17:31:58 <mazz> <destination-base-dir>...install.dir...</destination-base-dir>
17:31:58 <mazz> <destination-base-dir>...deploy.dir...</destination-base-dir>
17:32:23 <mazz> did you get that? just got a message that this channel got flooded. not sure if that went out
17:32:34 <ccrouch> yep i saw that
17:32:50 <mazz> essentially, perhaps we propose multiple base dirs in the XML descriptor
17:32:53 <mazz> so in your example ccrouch
17:32:59 <mazz> you would have to pick which one you wanted
17:33:09 <mazz> which in your case would be the deploy dir
17:33:39 <mazz> if I wanted to patch them
17:33:47 <mazz> I would pick the "install.dir" one
17:33:57 <mazz> this is not on the wiki btw :)
17:34:12 <mazz> but I do allude to the fact that we can extend this XML - and this is what I was thining
17:34:14 <mazz> thinking
17:34:30 <ccrouch> right
17:34:32 <ips> and if we supported multiple dest dirs, we might also want to have sort of the reverse of the targetResourceTypes bundle recipe attribute i suggested above
17:34:43 <David-UP> Important to be able to specify the target location for both.  Same in the Tomcat (EWS) world where we run a single $CATALINA_HOME and multiple $CATALINA_BASE's...got to get the right one
17:35:08 <ips> eg: <destination-base-dir bundleTypes="jbossApplication">...deploy.dir...</...
17:35:47 <ips> and in the bundle recipe: <bundle type="jbossApplication" .../>
17:37:05 <mazz> ips: I was thinking kinda the same - it would be loosely related.. kinda just like a name. I'm not sure if hard-linking a recipe with a piece of plugin descriptor metadata would be confusing and hard for people to follow. but maybe I'm being too pessimistic again :}
17:37:10 <ips> and then when a user goes to deploy a bundle of type jbossApplication, the gui could only list the applicable target resources and the applicable destination dirs for those targets
17:37:21 <mazz> <base-dir name="Deploy Apps Here Location">
17:37:30 <mazz> <base-dir name="Core Server Location"...>
17:37:42 <mazz> and the UI would show those names that you pick from
17:37:50 <mazz> in your case, the nice thing is
17:37:55 <mazz> the user would have to pick anything
17:37:59 <mazz> the recipe declares which one to use
17:38:15 <ccrouch> (12:37:20 PM) mazz: <base-dir name="Deploy Apps Here Location">
17:38:15 <ccrouch> (12:37:28 PM) mazz: <base-dir name="Core Server Location"...>
17:38:15 <ccrouch> i prefer that
17:38:17 <mazz> so I can see that as being helpful and less error prone
17:38:36 <ccrouch> (12:37:53 PM) mazz: the user would *NOT* have to pick anything
17:38:37 <ccrouch> :-)
17:38:43 <ccrouch> that is a big win imho
17:38:43 <mazz> doh
17:38:46 <David-UP> Yes.
17:39:20 <ips> ccrouch: now i'm confused - you prefer my idea or mazz's?
17:39:28 <mazz> David-UP: this would require people writing the bundle recipe XML to know what name to assign to it. and that name would be fond in the plugin descriptor (or documentation somewhere)
17:39:38 <ips> mine is the idea where the user wouldn't have to pick anything
17:40:04 <ccrouch> ips: it should be optional
17:40:41 <mazz> today, that recipe is pretty isolated from the server/agent. that is, you just need to write the XML using the proper bundle XML elements. but I don't think you need to know anything about plugin descriptor metadata,or resource type names or things like that
17:40:44 <ips> agreed, for backwards compatibility and in case people just don't care to use it
17:41:17 <ccrouch> ips: i'm sorry i didnt see your idea in full because my irc died
17:41:17 <ccrouch> but the idea of naming those properties so people *can* choose based on name is good, letting the recipe state which one should be used is a really good addition
17:41:21 <mazz> if its optional, we would still have to build a UI component to pick the destination.
17:41:34 <David-UP> simpler for me to apply a Tomcat use case.  I may have four virtuals with three instances of Tomcat containers on each virtual forming three Tomcat "clusters"  The three instances share the same $CATALINA_HOME.  I may want to 1) patch the base binaries with something like a new tomcat-juli.jar, 2) deploy and app to cluster "3", 3) deploy a new spring.jar to the shared library folder of cluster "2).  Mechanism should work for all those,
17:42:07 <mazz> yeah, I think this would solve those use -cases
17:42:16 <David-UP> Sounds like it me :_
17:42:53 <ips> if the recipe doesn't specify targetResourceTypes, gui would assume it can be deployed to any type of resource that is a bundle target, and if the recipe doesn't specify bundleType, gui would assume it can be deployed to any dest dir
17:42:58 <mazz> ok, it's a good thing I'm recording this :} I'll add this stuff (ips' suggestions, and David-UP's use case) to the iwki later
17:43:23 <mazz> ips: I like that. optional configurability
17:43:43 <David-UP> Good discussion, folks, look forward to reading the summary, but I have to go prepare for a meeting at the top of the hour....
17:43:53 <mazz> thanks for the insight David-UP- it helped
17:43:56 <ccrouch> thanks David-UP
17:44:02 <David-UP> You're all welcome!
17:44:22 <ccrouch> mazz: these properties would need to be configurable via the resources connection properties
17:44:31 <ccrouch> so people could tweak them as the needed
17:44:40 <ccrouch> List-o-Maps?
17:44:42 <mazz> yup.. that's the pluginConfiguration[install.dir] notation I put on the wiki
17:45:23 <ccrouch> so the properties themselves would still show up in the connection props?
17:45:41 <mazz> yes. we would be using connection props
17:45:46 <mazz> probably could use existing ones
17:45:54 <mazz> wouldn't need to add any (at least for JBossAS resources)
17:45:59 <ccrouch> not quite what i mean
17:46:25 <ccrouch> as  user, how do i change <base-dir name="Deploy Apps Here Location">
17:46:38 <mazz> you chane the plugin config value that it refers to
17:46:44 <mazz> that base-dir is just a "reference" sort to speak
17:46:50 <mazz> to either 1) a plugin config
17:46:52 <mazz> 2) a resource config
17:46:52 <ccrouch> hmm :-(
17:46:54 <mazz> 3) a metric
17:46:58 <mazz> see the wiki
17:47:06 <mazz> http://rhq-project.org/display/RHQ/Design-BundleDeploymentToNonPlatforms#Design-BundleDeploymentToNonPlatforms-AgentPluginDescriptor
17:47:13 <mazz> <destination-base-dir>pluginConfiguration[install.dir]</destination-base-dir>
17:47:18 <mazz> <destination-base-dir>resourceConfiguration[install.dir]</destination-base-dir>
17:47:22 <mazz> <destination-base-dir>trait[install.dir]</destination-base-dir>
17:47:29 <ccrouch> right, but *where* do i make that change
17:47:46 <ccrouch> in the connection props page?
17:47:57 <mazz> not following - you aren't changing the actual reference of "pluginConfig[install.dir]"
17:48:02 <mazz> but you are changing "install.dir"
17:48:05 <mazz> or whatever it is
17:48:15 <mazz> if it's a resourceConfiguration reference
17:48:20 <mazz> you are changing the Config tab configuration
17:48:32 <ccrouch> but somebody is bound to want to deploy something to somewhere we havent thought of
17:48:35 <mazz> if it's a trait, you have no ability to change it - the plugin author is saying "deploy it to the value of this trait"
17:48:50 <mazz> use platform bundles :)
17:48:58 <mazz> or
17:49:02 <mazz> we add this:
17:49:15 <mazz> <destination-base-dir location="Custom">pluginConfiguration[custom.dir]</destination-base-dir>
17:49:16 <ccrouch> and i dont want to create a million <destination-base-dir> for every conceivable trait/resource/pluginConfig
17:49:46 <mazz> and we add a new "custom.dir" (call it "Custom Deployment Location") to the pluginConfiguration of the resource
17:49:52 <mazz> and the user to point it to where ever they want
17:50:06 <mazz> thus we would have 3 common locations
17:50:10 <mazz> 1) the core install dir (for patching)
17:50:15 <mazz> 2) the standard deployment location
17:50:19 <ccrouch> why not just make destination base dir a List-O-Maps in the connection props with two know defaults and then let people add to it
17:50:20 <mazz> 3) some user-defined custom location
17:51:06 <lkrejci> ccrouch: list-o-maps is metadata, so we'd have problems defining a list of defaults
17:51:10 <mazz> well, for JbossAS case, we already have the two in existing plugin configs no?
17:51:17 <mazz> the deployment/config set dirctory and the insatll directory
17:51:28 <mazz> now we are introducing new plugin configs that store the same data
17:51:39 <ccrouch> (12:49:44 PM) mazz: and we add a new "custom.dir" (call it "Custom Deployment Location") to the pluginConfiguration of the resource
17:51:39 <ccrouch> i guess my version just makes all dirs customizable
17:51:52 <mazz> ccrouch: right - and I don't think we want that
17:52:07 <mazz> I mean, I guess you could remove the install.dir and deploy.dir one
17:52:10 <mazz> or change it
17:52:18 <mazz> but changing it would be bad
17:52:29 <mazz> at least in the standalone install.dir and eploy.dir props, I think we mark tham as read-only
17:52:52 <mazz> there is another alternative to support custom delpoyments
17:52:59 <mazz> I have this on the wiki already
17:53:26 <mazz> (if I can find it...)
17:53:48 <ccrouch> lkrejci: don't we do this already for stuff like the jbossas logtracking
17:53:58 <mazz> "Other than this new query that needs to be used, the wizards can probably remain as-is. The user can still specify a destination directory as always. Today, this is the full, absolute path of where the bundle is to be deployed on the platform's file system. However, if the user specifies a relative path, it can be relative to the <destination-base-dir>, thus allowing the user to deploy to a subdirectory under the resource."
17:54:03 <ccrouch> thats a list of maps right, and it always has one entry in it
17:54:06 <mazz> in other words, you can select the "Core Server Location"
17:54:16 <mazz> and the deploy destination directory you specify is relative to that
17:54:21 <mazz> which can be anything you want
17:54:33 <mazz> thus allowing you to deploy anywhere under the core install dir
17:55:14 <ccrouch> mazz: but if it varies per instance, which it will do if its beneath the configuration named folder, you are back to square 1
17:55:29 <mazz> I just think it seems odd that we'd be duplicating propery values
17:55:32 <lkrejci> mazz: that would require that the "where" is homogenous across the group you're deploying to
17:55:43 <mazz> I have this config set/deploy dir lcoation and install.dir already
17:55:46 <mazz> as read-only props
17:56:01 <mazz> but now I'm also putting in the same values in a list-o-maps in plugin config, that I can modify
17:56:17 <ccrouch> you could just but the references in there
17:56:41 <mazz> hmmm
17:56:49 <ccrouch> maybe this is too complicated
17:56:58 <ccrouch> too flexible
17:56:59 <mazz> that would mean we don't even need the <destination-base-dir> XML in the decriptor
17:57:39 <mazz> I'm thinking...
17:57:43 <mazz> this has potential... lemme think
17:57:59 <mazz> (I'm thinking, you could even put in hardcoded paths in this list-o-map if you wanted... as a custom location)
17:58:31 <ccrouch> i think having "installDir" and "DeployDir" as places people can choose to deploy stuff too, is a good. or letting the recipe specify "installDir" or "deployDir" to set the preference is good too
17:58:48 <mazz> for example, if this resource was installed via rpm, and the content is scattered all over the place on the file system that we can't auto-detect... maybe this could help?
17:59:12 <mazz> we'd still have those names - those are the keys to the list of maps
18:00:12 <ccrouch> one issue with this approach is that all the resources in the group you are deploying to have got to have the selected base-dir property defined
18:00:52 <ccrouch> you cant add "myCustomPath" to one AS instance, then try to deploy to there across a group of instance
18:00:53 <ccrouch> s
18:01:04 <mazz> right.
18:01:26 <mazz> whereas if it's a "required" plugin config property
18:01:32 <mazz> we know they will always be there
18:01:43 <ccrouch> maybe "hardcoding" the options would be less error prone
18:01:46 <ccrouch> right
18:02:24 <mazz> the only value-add to the list-o-maps that I see is the ability to add more than one custom location
18:02:33 <mazz> that does have potential value though.
18:02:43 <mazz> but
18:02:52 <ccrouch> your version of two "hardcoded" properites and one new "customDir" property is not a bad compromise
18:03:13 <mazz> ok, I think I agree. the only thing we don't get that list-o-maps gives us is MULTIPLE custom locations
18:03:30 <ccrouch> right
18:03:53 <ccrouch> in the future we could always suck that "customDir" into a list-o-maps as part of an upgrade
18:04:00 <mazz> but not using list-o-maps gives us the "less error prone" stuff.
18:04:11 <mazz> yeah.. ok, so.. we'll add the "custom.dir" thing
18:04:16 <mazz> but keep the rest as it was on the wiki
18:04:41 <mazz> ok, its been 60minutes
18:04:52 <mazz> I think we can call it and shutdown the "meeting"
18:05:03 <mazz> I'll capture the log and post it somewhere
18:05:12 <mazz> this was a good discussion. lots of new ideas I didn't think of
18:05:48 <ccrouch> cheers
18:06:04 <mazz> #endmeeting