/
fluid-tech IRC Logs-2013-09-04

fluid-tech IRC Logs-2013-09-04

Sept 04, 2013

[11:41:27 CDT(-0500)] <sgithens> clown, it does look pretty cool

[11:41:35 CDT(-0500)] <sgithens> I have a few friends on campus that use it

[11:41:45 CDT(-0500)] <sgithens> oops

[11:41:51 CDT(-0500)] <clown> huh?

[11:41:51 CDT(-0500)] <sgithens> I meant colinclark

[11:41:58 CDT(-0500)] <sgithens> sublime text

[11:41:58 CDT(-0500)] <clown> ah, okay.

[14:06:42 CDT(-0500)] <avtar> Bosmon2, Bosmon8: ping

[15:39:50 CDT(-0500)] <yzen> so Bosmon2 and I were chatting about the lifecycle manager and how it will be wrapped into a kettle.app

[15:40:27 CDT(-0500)] <yzen> i was asking either Bosmon2 or Bosmon8 about the preferred name for the component that currently represents the lifecycle manager

[15:40:45 CDT(-0500)] <yzen> but will end up being an additional grade for the life cycle manager kettle app

[15:41:33 CDT(-0500)] <Bosmon2> Is the discussion different, depending on whether it is a base grade or a subcomponent?

[15:41:41 CDT(-0500)] <Bosmon2> I imagine it should be mostly the same ....

[15:41:45 CDT(-0500)] <yzen> yes

[15:41:55 CDT(-0500)] <yzen> it mostly the same

[15:42:05 CDT(-0500)] <yzen> and not sure what the base grade really means

[15:42:18 CDT(-0500)] <yzen> since the new lifecycle manager app will have 2 base grades

[15:42:27 CDT(-0500)] <Bosmon2> You said "end up being an additional grade"

[15:42:29 CDT(-0500)] <yzen> kettle.app and the original lifecycle manager component

[15:42:31 CDT(-0500)] <Bosmon2> Yes

[15:42:34 CDT(-0500)] <yzen> yes

[15:42:41 CDT(-0500)] <Bosmon2> That is certainly one way of implementing it

[15:42:56 CDT(-0500)] <Bosmon2> So I guess namespacing and IoC name resolution can make this awkward

[15:43:03 CDT(-0500)] <Bosmon2> Given we have a namespace gpii.lifecycleManager

[15:43:09 CDT(-0500)] <Bosmon2> Which at the moment refers to the thing itself

[15:43:25 CDT(-0500)] <Bosmon2> I don't know if it would be awkward to refer to the app as gpii.lifecycleManager.app

[15:43:25 CDT(-0500)] <yzen> correct

[15:43:31 CDT(-0500)] <yzen> it will be

[15:43:41 CDT(-0500)] <yzen> because externally app is meaningless

[15:43:51 CDT(-0500)] <Bosmon2> Since the name "app" appearing in resolution might cause ambiguity

[15:44:03 CDT(-0500)] <Bosmon2> In what way is it meaningless?

[15:44:12 CDT(-0500)] <Bosmon2> You mean, because every other GPII server is just named after itself?

[15:45:22 CDT(-0500)] <yzen> it becomes slightly different from the rest of the naming of apps that we have and slightly harder to follow, because really unless you are interested in the internals of the lifecycle manager app, you only know about the "gpii.lifecycleManager"

[15:46:19 CDT(-0500)] <Bosmon2> I see that the current implementation of LifecycleManager is extremely ancient in any case

[15:46:40 CDT(-0500)] <yzen> it is already chaining as we speak

[15:46:45 CDT(-0500)] <Bosmon2> great

[15:46:51 CDT(-0500)] <Bosmon2> Are you using wire's "reduce" scheme?

[15:47:51 CDT(-0500)] <yzen> Bosmon2: not yet

[15:48:05 CDT(-0500)] <yzen> that will be done only after i make sure flow manager is split up from the lifecycle manager

[15:48:09 CDT(-0500)] <Bosmon2> Ok, so it seems we frequently use the suffix "Server" for those things which are servers

[15:48:18 CDT(-0500)] <Bosmon2> How about naming the actual app as "LifecycleManagerServer"?

[15:48:57 CDT(-0500)] <yzen> that's the thing i was hoping to keep the server as "lifecycleManager" and have the current one being "lifecycleManager[SOMETHING]"

[15:51:09 CDT(-0500)] <Bosmon2> Well, it's awkward that our architecture is messed up in other areas

[15:51:22 CDT(-0500)] <Bosmon2> For example the MatchMaker is not structured properly in this way, so it isn't useful as a template for this problem

[15:51:38 CDT(-0500)] <Bosmon2> It only exists in the "app" variant and all of its polymorphism is just stuffed onto the app itself

[15:51:45 CDT(-0500)] <yzen> yes

[15:51:47 CDT(-0500)] <Bosmon2> Rather than there being any such thing as a "real Matchmaker"

[15:52:05 CDT(-0500)] <Bosmon2> So in a sense this is the first time we encounter this problem ....

[15:54:48 CDT(-0500)] <Bosmon2> One thing yzen - I wonder if there is a way we can adjust the "promise returning" aspect of DataSource to occur through grade addition

[16:21:59 CDT(-0500)] <avtar> Bosmon2, kasparnet: hi

[16:23:19 CDT(-0500)] <avtar> do either of you know if someone has tried using the preferences server with couchdb 1.4 release?