[00:14:20] <bobmcw> ALR: my favorite line of "code" written today: https://github.com/torquebox/torquebox/blob/master/integration-tests/pom.xml#L176
[00:25:34] <ALR> bobmcw: haha
[00:32:45] *** rruss has quit IRC
[00:40:45] <aslak> how do you like my experimental Reflection Query API? http://arquillian.pastebin.com/5Zhu6j1F
[00:59:16] *** lightguard_jp has quit IRC
[00:59:34] <aslak> ALR, ^
[00:59:46] * ALR lookin
[01:00:00] <aslak> no nagging, just in case you didn't catch it.. ;)
[01:00:03] <ALR> aslak: What are we querying
[01:00:05] <ALR> And why?
[01:00:11] <ALR> (I didn't catch it)
[01:00:28] *** lightguard_jp has joined #jbosstesting
[01:00:30] <aslak> querying for metadata matches
[01:00:49] <aslak> why because we're sick of doing reflection using the java.lang.reflect.. :)
[01:00:55] <ALR> Hehe.
[01:01:03] <ALR> So this is a wrapper around jl.r?
[01:01:12] <aslak> yea
[01:01:20] <ALR> And additionally an abstraction I'd imagine.
[01:01:26] <ALR> You could plug it into JBREFLECT
[01:01:31] <ALR> And get a Javassist backend
[01:01:37] <ALR> For free
[01:01:58] <aslak> basically, from a class pool, find me all, classs or field or method that match x and x and x
[01:02:10] <aslak> and wrap them in a 'Object' of some sort..
[01:02:46] <ALR> OK, explain MethodDescriptor, FieldDescriptor for me?
[01:03:03] <ALR> Seems you already have Query.forMethod(), Query.forField()
[01:03:12] <ALR> Which should be enough to return the right type, no?
[01:03:16] <aslak> currently, it's just any object to wrap the matches
[01:03:30] 
[01:03:37] <aslak> for each a in matches create new MethodDescriptor(a)
[01:03:53] <ALR> MethodDescriptor.class is used there to satisfy the generics only?
[01:04:00] <aslak> no
[01:04:18] <aslak> it's a wrapper around e.g. a Field
[01:04:29] <ALR> Yes, but why pass in as an arg?
[01:04:30] <aslak> give me all Fields matching the Query as a X
[01:05:45] <ALR> And Query.forField() can't do that?
[01:05:55] <aslak> a shortcut for: for(Field field: query...()) { new FieldDescriptor(field)}
[01:05:57] <ALR> Or you can't get all the info you need from it?
[01:06:04] <aslak> two different things
[01:06:17] <ALR> I'm just looking at the above line
[01:06:25] <ALR> This one:
[01:06:25] 
[01:06:35] <ALR> You want out a Collection<MD>
[01:06:45] <aslak> query(Query) returns a Collection<X>, X being Field|Method|Class
[01:06:45] <ALR> service.query provides that
[01:06:52] <ALR> Yep.
[01:07:00] <aslak> query(T, Query) wraps the result in T
[01:07:09] <ALR> And based upon the type of query, it can't know what T is?
[01:07:24] <ALR> Trying to save you a user argument.
[01:07:32] <aslak> T has nothing to do with the Query
[01:07:41] <ALR> The flow of the API makes a lot of sense.  It's intuitive for sure.
[01:07:47] <aslak> T is the users wrapper object for handling a Field
[01:07:53] <ALR> Yes.
[01:08:05] <ALR> And doesn't a query infer a type T?
[01:08:07] <lightguard_jp> I'm looking at it, I like what I see :)
[01:08:20] <ALR> For instance Query.forMethod with never make T a ClassDescriptor
[01:08:27] <ALR> There's a relationship between the two.
[01:08:37] <ALR> Whether it's in code now or not :)
[01:08:45] <aslak> ok, ignore the names ClassDescriptor, thats just the test names
[01:09:14] <aslak> a more realistic name would be; query(DeploymentDescriptor.class, Query.forMethod().withAnnotation(Deployment.class))
[01:09:15] <ALR> MethodDescriptor, ClassDescriptor, FieldDescriptor, those are test names?
[01:09:24] <ALR> Sure.
[01:09:30] <ALR> Ahhh.
[01:09:32] <ALR> I see.
[01:09:38] <aslak> Query in this case knows Method
[01:10:02] <ALR> @Deployment > DeploymentDescriptor
[01:10:07] <aslak> DeploymentDescriptor is my object that can handle a Method, e.g. extract info, keep state about it etc
[01:10:13] <ALR> @Method > MethodDescriptor ?
[01:10:22] <aslak> on
[01:10:23] <aslak> no
[01:10:53] <aslak> the first param can be 'anything' you like it to be.. it's what you would use further on in your app
[01:10:59] <ALR> MethodDescriptor == analagous to j.l.r.Method ?
[01:11:05] <aslak> no
[01:11:09] <ALR> Sheesh.
[01:11:18] <ALR> I'm not grokking this then.
[01:11:22] <ALR> Can we try this another way?
[01:11:27] <aslak> ALR, ok, think @ResultMapper in sql
[01:11:34] 
[01:11:44] <aslak> execute this query, and 'map' it as a X
[01:11:46] <ALR> Can you explain for me in English what happens here, from the inside out>
[01:11:47] <ALR> ?
[01:11:53] <aslak> where X is not mapped, but wrapped in this case
[01:12:06] <lightguard_jp> The Query will instantiate and populate an instance of the first class (DeploymentDescriptor in the above)?
[01:12:16] <aslak> lyes
[01:12:19] <aslak> lightguard_jp, yes
[01:12:26] <ALR> Breaking it down: Query.forMethod().withAnnotation(Deployment.class).ofType(Archive.class)
[01:12:41] <ALR> Query all methods with @Deployment and a return type of Archive ?
[01:12:49] <aslak> Query.forField will find a bunch of Fields. for Each found Field, wrap it in a 'X' and return the Collection
[01:13:19] <ALR> ^
[01:13:42] <aslak> ALR, ok, this could be a scenario
[01:13:51] <lightguard_jp> aslak: Does the class you pass into query have to implement an interface or anything?
[01:13:54] <ALR> aslak: Can you answer?
[01:14:04] <aslak> Query.forMethod().withAnnotation(Deployment.class) -> this internally gives you a list of Methods
[01:14:15] <ALR> Hehe, back up.
[01:14:26] <ALR> Query.forMethod().withAnnotation(Deployment.class)
[01:14:33] <ALR> What does this return?  What type?
[01:14:38] <aslak> but you don't care about them, you make a wrapper, Deployment(Method) { Archive<?> getArchive() {return method.invoke()}};
[01:14:52] <ALR> That's all impl stuff.
[01:14:55] <ALR> User don't care.
[01:15:52] <aslak> ALR, well, a User of this is a dev, and in that Case, the Dev is interested in his created Wrapper for Methods of type @Deployment.. not Method
[01:16:15] <ALR> :)
[01:16:19] <ALR> I wanna back up.
[01:16:25] <ALR> Query.forMethod().withAnnotation(Deployment.class)
[01:16:32] <ALR> What is returned?
[01:17:20] <aslak> lightguard_jp, currently it is a Desc<T> interface, where T is the Query return type. but it's not really used beyond generics: public <X, T extends Desc<X>> List<T> query(Class<T> type, QueryExecuter<X> query)
[01:17:43] <aslak> ALR, Collection<Method>
[01:17:48] <ALR> aslak: Code in a repo somwhere?
[01:17:53] <aslak> nope
[01:18:17] <ALR> aslak: OK, recommend you abstract out Method.
[01:18:24] <ALR> aslak: Like this flows real nice.
[01:18:36] <ALR> But I suspect you can slim it a bit to require less from the user.
[01:18:41] <aslak> abstract out Method?
[01:18:55] <ALR> Yeah, unless you think a user wants access to j.l.r.Method
[01:19:15] <ALR> (And I thought the point was to wrap/abstract out the reflection API, in which case I'm missing the goal here)
[01:19:28] <ALR> Maybe you just want a nicer query API than reflection provides.
[01:19:41] <aslak> the plan wasn't(currently) to reimpl a complete abstraction layer on top of reflections, only a query mechanizem
[01:19:53] <ALR> But if you completely hide away the reflection API, then you got a supernice query API you can hook into any backend.
[01:20:09] <lightguard_jp> aslak: You have to register all the classes you want it to search over?
[01:20:12] <ALR> So there's 2 concerns here:
[01:20:15] <aslak> lightguard_jp, yea
[01:20:22] <ALR> 1) Query API for Reflection
[01:20:28] <ALR> 2) How reflection is done.
[01:20:29] <aslak> lightguard_jp, could be changed, but that's the current use case
[01:20:33] <ALR> I recommend abstracting out 2)
[01:20:38] <ALR> So you can get other backends.
[01:20:42] <ALR> Which would make this:
[01:20:46] <ALR> 1) Faster possibly
[01:20:50] <ALR> 2) Not require ClassLoading
[01:21:08] <ALR> As a bonus you could probably trim your API a bit.
[01:21:26] <ALR> If it didn't return Collection<Method> you wouldn't need to wrap this in your own descriptor type.
[01:21:44] <aslak> ALR, your missing the point of the wrapping
[01:22:15] <ALR> aslak: I don't think I am.  I represented it in my point 1) above.  You're wrapping to make a query API better than the Reflection library.
[01:22:25] <aslak> ALR, no
[01:22:38] <aslak> i'm wrapping because that is my Domain object
[01:22:42] <ALR> Then yes, I'm absolutely missing the point of what you're trying to do
[01:22:45] <ALR> :)
[01:23:20] <ALR> Oh, you're talking about a different "wrapping".  I meant "your API is wrapping Reflection"
[01:23:29] <ALR> Not "wrapping Descriptors over some type".
[01:23:30] <aslak> aa no
[01:23:45] <ALR> We need more frikken words.
[01:24:01] <ALR> Yeah, I haven't gotten into your object wrapping yet.
[01:24:03] <aslak> the wrapping is just a convinience for having to do a new loop of the query result.
[01:24:38] <ALR> To turn Collection<Method> into Collection<MethodDescriptor> ?
[01:24:42] <aslak> yea
[01:25:01] <ALR> (07:17:52 PM) ALR: If it didn't return Collection<Method> you wouldn't need to wrap this in your own descriptor type.
[01:25:12] <ALR> That's what I meant.
[01:25:30] <ALR> I'm down with all of your Query.forMethod stuff.
[01:25:40] <aslak> i see the confusion based on the name choice in my test case
[01:25:41] <ALR> It's service.query() I'm iffy on.
[01:25:59] <aslak> MethodDescriptor is not my Abstraction over Method
[01:26:10] <ALR> service.query( Class newTypeToWrapIn, Collection<X> realResult) ; ... right ?
[01:26:12] <aslak> MethodDescriptor is the users Domain object
[01:26:32] <aslak> yea
[01:26:39] <ALR> OK, great.
[01:27:04] <ALR> So service.query's job is to take a Collection and for each element, wrap it in something else, returning the new Collection.
[01:27:24] <ALR> Doesn't sound like a "query" to me.
[01:27:30] <ALR> That sounds like "wrapping"
[01:27:33] <ALR> Or something else.
[01:27:57] <ALR> All of the Query.forX stuff I see looks nice.
[01:28:19] <ALR> I think the naming of QueryService and .query() are misleading.
[01:28:24] <aslak> Service has the class pool to scan, and a stateful store for the Descriptors.. so a new Query for a 'Descriptor' that match the same Type will return the same Descriptor instance
[01:29:00] <ALR> aslak: Why is that important?
[01:29:14] <ALR> aslak: ie. why do you need a class pool, stateful cache?
[01:29:49] <aslak> well, the 'class pool' is to limit the scan. i'm not scanning the classpath, but i have these # classes i want to scan
[01:30:16] <aslak> Query is just a value object.. QueryService has the database and is the one that can do the query
[01:30:36] <ALR> Query is more than a VO.
[01:30:50] <ALR> It has static methods to make new queries.
[01:30:57] <ALR> Making it also a factory.
[01:31:02] <aslak> it's a builder
[01:31:08] <aslak> but besides the point
[01:31:48] <aslak> it's not service.query(Type, Collection<Result>), but service.query(Type, Query)
[01:31:51] <ALR> QueryService is not doing the query.
[01:32:03] <ALR> Oh.
[01:32:05] <ALR> Hang on
[01:32:30] <ALR> (07:12:51 PM) ALR: Query.forMethod().withAnnotation(Deployment.class)
[01:32:30] <ALR> (07:12:58 PM) ALR: What is returned?
[01:32:31] <ALR> (07:14:09 PM) aslak: ALR, Collection<Method>
[01:32:44] <ALR> aslak: ^
[01:33:00] <aslak> sorry, internally
[01:33:36] <ALR> aslak: Query.forMethod returns Query ?
[01:33:44] <aslak> yea
[01:33:52] <ALR> Hehe.
[01:34:00] <ALR> aslak: Push this somewhere, I'd love to see.
[01:34:06] <aslak> or it reutrns a MethodQuery but
[01:34:11] <ALR> It's a bit harder w/out access to the API
[01:34:39] <ALR> I get that you'd use a service to execute a query.
[01:34:52] <ALR> I get that you'd use Query.forMethod as a factory/builder thing
[01:35:06] <ALR> I don't get why you'd wrap alongside the execution of the query.
[01:35:06] <aslak> so far so good
[01:35:11] <ALR> I think those are two different things.
[01:35:14] <aslak> to slow
[01:35:58] <aslak> i have both.. service.query(Query) and service.query(Type, Query)
[01:36:17] <ALR> Also, since this is a query mechanism I still think you should remove all API references to j.l.r
[01:36:22] <ALR> If there are any.
[01:36:33] <aslak> there are..
[01:36:36] <ALR> And make hooks to use any underlying store.
[01:36:48] <ALR> That would really make this thing pretty awesome.
[01:36:50] <aslak> and query impl as well then
[01:36:57] <ALR> Because it's a great/powerful API you have.
[01:37:12] <ALR> And JBREFLECT/Javassist are powerful backends.
[01:37:25] *** michaelschuetz has quit IRC
[01:37:40] <ALR> So all in all I'd separate out just the query API part of that for this project
[01:37:44] <ALR> And define that as your scope.
[01:39:05] <lightguard_jp> I think this would be a really powerful tool
[01:39:12] <lightguard_jp> Be really nice weld / solder
[01:39:15] <aslak> so far the scope has been, we do a lot of reflection in arq, and so will all the extensions.. with multiple possible classes etc comming in suite we should probably have a nicer api to hide some of the dirty work.. so it doesn't have to be reimplemented over and over
[01:40:02] <aslak> but, i gotta get to bed..
[01:40:07] <ALR> Hehe, that's not scope. :)
[01:40:11] <ALR> That's your use case.
[01:40:16] <aslak> i'll get it pushed out somewhere.. :)
[01:40:22] <ALR> aslak: You're sorry you asked, aren;t you? :D
[01:40:27] <aslak> hehe
[01:40:28] <ALR> Goodnight bud.
[01:40:29] <aslak> not at all
[01:40:48] <aslak> well, when i have impl my use case, that's my scope right? :)
[01:40:59] <ALR> To be continued.
[01:41:01] <lightguard_jp> I'm very interested to see where this goes
[01:41:02] <aslak> hehe yea
[01:41:06] <lightguard_jp> Sleep well aslak
[01:42:29] <lightguard_jp> Yep
[01:46:21] *** jc3 has joined #jbosstesting
[02:06:25] *** aslak has quit IRC
[02:44:49] *** lightguard_jp has quit IRC
[04:10:25] *** ldimaggi_ has quit IRC
[04:46:23] <jbossbot> git [shrinkwrap] push master df6f5bc.. Andrew Lee Rubinger [SHRINKWRAP-117] Do not allow export of an archive to an existing directory
[04:46:25] <jbossbot> jira [SHRINKWRAP-117] Inconsistencies in the API of what File means [Resolved, Major, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKWRAP-117
[04:46:25] <jbossbot> git [shrinkwrap] push master 0ee0c1f.. Andrew Lee Rubinger [SHRINKWRAP-117] Do not allow import of dirs as stream-based, give good exception message
[04:46:25] <jbossbot> git [shrinkwrap] push master 1a56285.. Andrew Lee Rubinger [SHRINKWRAP-238] Refactor Container add* methods to denote we are adding *to* an archive, and what we are adding *from* is based on input type
[04:46:25] <jbossbot> jira [SHRINKWRAP-238] Rename *Container add* methods to be more descriptive [Open, Major, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKWRAP-238
[04:46:26] <jbossbot> git [shrinkwrap] push master 198c276.. Andrew Lee Rubinger Merge branch 'SHRINKWRAP-238' of github.com:ALRubinger/shrinkwrap into SHRINKWRAP-238
[04:46:26] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/77bbba7...198c276
[05:20:05] *** rruss has joined #jbosstesting
[06:25:31] <bobmcw> ALR: I read that tweet as "In the name of charity..."
[06:26:15] <ALR> Haha
[06:26:30] <ALR> bobmcw: Tonight it's scotch, coding, and Empire Records.
[06:26:43] <ALR> Love Netflix.
[06:26:48] <bobmcw> is that the one with Brenden Fraser?
[06:26:53] <bobmcw> Steve Buscemi?
[06:26:56] <ALR> Nope.
[06:26:59] <bobmcw> hm
[06:27:13] <ALR> It's Liv Tyler, Renee Zellweger...
[06:27:24] <ALR> Rory somethingorother, Demi Mazar
[06:27:28] <bobmcw> Renee is too squinty for me
[06:28:02] <ALR> Given the option, I'd forgive that.
[06:46:12] *** lightguard_jp has joined #jbosstesting
[06:48:11] *** lightguard_jp has quit IRC
[08:22:10] <ALR> bobmcw: Still here?
[09:02:52] *** maeste has joined #jbosstesting
[09:05:33] *** mgoldmann has joined #jbosstesting
[09:31:01] *** ALR has quit IRC
[09:35:18] *** rruss has quit IRC
[10:50:23] *** maeste has quit IRC
[12:53:15] *** aslak has joined #jbosstesting
[12:53:16] *** aslak has quit IRC
[12:53:16] *** aslak has joined #jbosstesting
[13:19:06] *** ALR has joined #jbosstesting
[13:21:08] <ALR> aslak: Hey-o.
[13:44:35] <aslak> ALR, heya
[13:46:52] <aslak> jira seems down
[13:47:27] <ALR> There was some scheduled maintenance notice I saw earlier
[13:47:31] <aslak> aa
[13:51:10] <aslak> ALR, up early on a saturday ?
[13:51:37] <ALR> aslak: Yeah.
[13:51:41] <ALR> Seize the day and all.
[13:51:46] <aslak> hehe
[13:51:54] <ALR> I'm 1/2way into that JIRA Dan wants.
[13:52:03] <ALR> WebArchive refactoring
[13:52:21] <ALR> And I pushed those "addAs" changes
[13:52:34] <ALR> So now everything you have...will break.
[13:52:40] <aslak> yea!
[13:52:42] <aslak> :)
[13:52:48] <ALR> I don't mind doing the SW upgrade for ARQ, BTW
[13:52:58] <ALR> Probably best that I do, actually.
[13:53:59] <aslak> a thought that came to me this morning..  the addAs refactoring will make the api a bit more verbose
[13:54:21] <ALR> == Clear.
[13:54:30] <aslak> sure
[13:54:33] <ALR> :P
[13:55:21] <ALR> aslak: I think of it like this:
[13:55:40] <ALR> When I put dough into the oven, I don't say "Add Bread"
[13:55:47] <ALR> Because I'm not adding bread.
[13:55:50] <ALR> I'm adding dough.
[13:56:08] <ALR> addDoughAsBread is verbose
[13:56:27] <ALR> So we remove the "dough" part, as it can be inferred by what we're adding
[13:56:31] <ALR> asAsBread(Dough)
[14:02:10] <aslak> bread being the expected output of putting dough in the oven.. i see the logic
[14:02:35] <ALR> It's not a perfect analogy, but I think it fits.
[14:02:44] <ALR> I always messed up the "addResource" thing.
[14:02:56] <ALR> Because the name infers you're adding a resource.
[14:03:06] <ALR> Not adding something "as a ClassPath resource"
[14:03:17] <aslak> but, if you just put Dough in the oven, what will appen?
[14:03:19] <aslak> happen
[14:03:32] <ALR> ShrinkWrap is always preheated.
[14:04:45] <aslak> our problem tho, is that dough can be multiple things.. so adAsSoup(Dough) :)
[14:04:57] <aslak> or can have multiple expected outcomes i mean
[14:05:19] <ALR> Yup
[14:05:54] <ALR> aslak: Are you unsatisfied w/ the current approach?
[14:06:00] <ALR> (Or the one I just put in place?)
[14:08:58] <aslak> no, i'm just bitchin.. ;)
[14:09:18] <ALR> Satisfied people don't complain  :)
[14:09:25] <ALR> I'm open to something better
[14:09:32] <aslak> i think my issue comes from somwehere else
[14:09:48] <ALR> But I suspect this iteration is the most sense we've got so far
[14:10:19] <aslak> looking at how users add stuff, i think we're failing with 'advanced' overrides, not method naming
[14:11:30] <aslak> a common thing seems to be, addManifestResource("src/main/resources/META-INF/name", "name") and then repeated 12 times
[14:11:55] <aslak> we're missing a directory import
[14:12:08] <aslak> or we have adirectory import via import and merge, but not in the api
[14:12:13] <ALR> Like, import everything in the dir?
[14:12:18] <aslak> yea
[14:12:23] <ALR> JIRA that
[14:13:11] <aslak> addManifestResource("src/main/resources/META-INF/*") <- add resources to META-INF, keeping only the relative name of target
[14:13:49] <aslak> jira is reindexing
[14:15:36] <ALR> Gotta run some errands
[14:15:38] <ALR> Back in a bit
[14:15:41] <aslak> sure
[14:26:36] *** maeste has joined #jbosstesting
[16:23:50] *** rruss has joined #jbosstesting
[19:37:04] *** rruss has quit IRC
[19:40:38] *** mgoldmann has quit IRC
[19:41:03] *** mgoldmann has joined #jbosstesting
[20:22:48] *** maeste has quit IRC
[20:28:50] *** jbossbot has quit IRC
[20:29:29] *** aslak has quit IRC
[20:29:34] *** aslak has joined #jbosstesting
[20:29:53] *** jbossbot has joined #jbosstesting
[21:37:42] <bobmcw> ALR: hey dude
[22:20:49] <aslak> bobmcw, do i remember correctly, reading a deltacloud api for steamcannon?
[22:21:00] <bobmcw> yes!
[22:21:20] <bobmcw> both the deltacloud API steamcannon itself uses to talk to EC2, plus the proxy it exports, per environment
[22:21:37] <bobmcw> lanceball is the guy who implemented the deltacloud we export
[22:21:48] <bobmcw> if you wanted to control steamcannon, you'd use that, plus the SteamCannon API
[22:21:55] <aslak> i'm not familiar with the api, but what can i do with it?
[22:21:56] <bobmcw> lance is working on clients for that, at least in ruby
[22:22:19] <bobmcw> so, SteamCannon API, you can set up an "environment" which is basically a cluster of AS, plus maybe a DB, etc
[22:22:27] <aslak> is th steamcannon ret api for full control up and running?
[22:22:29] <bobmcw> you can then start/stop the environment as a whole using SC-API
[22:22:35] <aslak> rest
[22:22:44] <bobmcw> if you want, you can poke inside the environment, and use Deltacloud API to start/stop individual nodes
[22:22:50] <bobmcw> ie, scale up/down the AS tier, if you like
[22:22:55] <bobmcw> yah, all REST
[22:23:17] <aslak> you expose deployment via sc api?
[22:23:26] <bobmcw> I think that's in-progress, but yes
[22:23:31] <bobmcw> deploy(thing)
[22:23:40] <bobmcw> whatevs
[22:23:45] <aslak> aa, but not currently released
[22:24:04] <bobmcw> aye, but next release should have it soon
[22:24:07] <aslak> i'll sit back and wait then.. :)
[22:24:10] <bobmcw> okie
[22:24:12] <aslak> got any doc on the rest ?
[22:27:56] <bobmcw> deltacloud API that we impl is documented, sorta, on deltacloud.org I think
[22:28:04] <bobmcw> steamcannon API lance will document shortly
[22:28:04] <aslak> yea
[22:28:09] <aslak> :)
[22:28:15] <bobmcw> nice, clean, curl-able API
[22:28:28] <aslak> sweet
[22:29:20] <bobmcw> aslak: and you can poke around a live deltacloud API here
[22:29:21] <bobmcw> http://try.steamcannon.org/deltacloud/api
[22:29:34] <bobmcw> username/passwd is your Amazon EC2 access_key and secret_access_key
[22:29:39] <bobmcw> if you get a http auth challenge
[22:29:51] <bobmcw> this is the DC-API that steamcannon itself uses to talk to EC2
[22:29:56] <bobmcw> it is *not* the impl we re-export
[22:29:59] <bobmcw> but gives you an idea
[22:30:16] <aslak> right, thanks
[22:30:21] <bobmcw> play with accepts: HTTP headers to get back XML or json
[22:31:09] <aslak> i like apis that have doc in the api
[22:31:18] <aslak> or impls that docs their apis i guess.. hehe
[22:31:34] <bobmcw> I do know there's a lot of out-of-date docs, so trust API over words
[22:32:16] <aslak> aa, so /api is not generated based on what is exposed by the server? e.g. javadoc
[22:33:25] <bobmcw> a) It's Ruby
[22:33:33] <bobmcw> b) No idea how linked docs are to impl
[22:33:56] <bobmcw> lanceball or bbrowning or tcrawley in #steamcannon on a workday are the guys who know more than I
[22:34:04] <aslak> javadoc was just a example.. :)
[22:46:16] *** mgoldmann has quit IRC
[23:35:25] *** lightguard_jp has joined #jbosstesting
[23:59:47] *** lightguard_jp has quit IRC





top