ruote log_2010-02-11

2010-02-11 06:37:15 utc anb_ Hello
2010-02-11 06:37:21 utc jmettraux Hello !
2010-02-11 06:37:30 utc jmettraux I'm about to push the wi == commit
2010-02-11 06:37:45 utc anb_ terrific
2010-02-11 06:38:02 utc jmettraux pushed, tell me if you need a formal release
2010-02-11 06:38:54 utc anb_ I can just pull, and use rake to build a gem right ?
2010-02-11 06:39:00 utc jmettraux yes
2010-02-11 06:39:20 utc anb_ that's fine then
2010-02-11 07:03:01 utc anb_ works beautifully John, thanks
2010-02-11 07:03:07 utc jmettraux great
2010-02-11 07:03:10 utc jmettraux you're welcome
2010-02-11 07:48:36 utc jmettraux tosch_le: good morning !
2010-02-11 09:21:36 utc anb_ I'm thinking about adding a "configuration" or "information" tab to ruote-kit with maybe engine config, registered participants, number of processes etc.
2010-02-11 09:23:26 utc jmettraux sounds good
2010-02-11 09:24:14 utc tosch_le number of processes should be visible in /processes, participants will be visible in /participants (kenneth said he'll be working on that soon)
2010-02-11 09:24:42 utc jmettraux maybe that could be part of /
2010-02-11 09:24:47 utc jmettraux the "start page"
2010-02-11 09:26:29 utc tosch_le yeah, dashbord-like
2010-02-11 09:26:34 utc anb_ true John but then tosch_le is right
2010-02-11 09:26:44 utc jmettraux dashboard ftw
2010-02-11 09:27:05 utc jmettraux overview
2010-02-11 09:27:15 utc anb_ yup
2010-02-11 09:27:51 utc anb_ looking forward to /participants and /errors, that will be nice
2010-02-11 09:29:47 utc tosch_le didn't get the use of /participants yet. i should now what participants i registered, shouldn't i? or will it be an overview of all _referenced_ participants? kenneth?
2010-02-11 09:32:03 utc jmettraux if you have 10+ ruote-kits running it could be good to GET /participants to know if there is something special/different in there
2010-02-11 09:33:52 utc anb_ yes, it all depends on how many participants you have and how many ruote-kit you manage
2010-02-11 09:34:15 utc anb_ but probably not critical
2010-02-11 09:34:32 utc jmettraux /errors is a must
2010-02-11 09:36:27 utc tosch_le ok, i've got somehow low demands here. a single rk will be sufficient... so agreed, for managing many/large rk instances, /participants is a nice to have
2010-02-11 09:49:53 utc anb_ tosch_le I added the filter by_field to GET workitems in a fork of your ruote-kit
2010-02-11 09:51:02 utc tosch_le didn't find your fork on github. i'd like to see your changes :-)
2010-02-11 09:52:58 utc tosch_le strange. now i can see your fork.
2010-02-11 09:53:19 utc anb_ oh ? well i'm new to github, maybe I did something wrong
2010-02-11 09:55:31 utc tosch_le your commit: http://github.com/anb/ruote-kit/commit/c5f95b0f025b48ffa560b00d1aa1e9a15f394169
2010-02-11 09:57:06 utc tosch_le you're doing an 'or' between the query strings there. i'm unsure if it shouldn't be an 'and'
2010-02-11 09:57:27 utc tosch_le especially when combining participant and fields query
2010-02-11 09:58:24 utc anb_ I think you're right
2010-02-11 09:58:49 utc anb_ "and" makes more sense
2010-02-11 09:59:02 utc anb_ I will actually need it later
2010-02-11 09:59:35 utc tosch_le yeah, but not necessarily for the participant query. 'or' is equally important there, i suppose
2010-02-11 10:00:08 utc tosch_le (and implemented in rk at the moment)
2010-02-11 10:05:37 utc anb_ "or" the participants, "and" for the fields
2010-02-11 10:05:47 utc anb_ and "and" the total ?
2010-02-11 10:06:11 utc tosch_le sounds reasonable
2010-02-11 10:06:37 utc anb_ it's a bit confusing the "or" for the participants, no ?
2010-02-11 10:06:52 utc tosch_le yes, it's counter-intuitive.
2010-02-11 10:07:28 utc anb_ I think "or" you can always run the query multiple times on client side, and "and" is more useful
2010-02-11 10:07:34 utc tosch_le but anding without having the possibility to or seems to be a no-go to me, too.
2010-02-11 10:07:53 utc tosch_le but each query means overhead.
2010-02-11 10:07:57 utc anb_ true
2010-02-11 10:08:12 utc anb_ another params to config behaviour ?
2010-02-11 10:08:45 utc tosch_le thinking about something like participant=foo|moo|mee&baz
2010-02-11 10:09:07 utc tosch_le but that's a complicated hell to parse, i suppose
2010-02-11 10:09:24 utc anb_ could be
2010-02-11 10:09:58 utc tosch_le maybe participant=foo,moo,mee,+baz?
2010-02-11 10:10:14 utc tosch_le like search engine queries in ancient times#
2010-02-11 10:10:59 utc tosch_le participants marked with + are required (and therefore anded), others are combined by or
2010-02-11 10:13:54 utc anb_ why not
2010-02-11 10:14:05 utc anb_ so defaults to "or" and prefix + means "and"
2010-02-11 10:24:42 utc anb_ but it's not trivial
2010-02-11 10:55:38 utc anb_ argh '+' doesn't play well in the URL
2010-02-11 11:31:06 utc tosch_le the same goes for &, so escaping ftw
2010-02-11 11:31:49 utc tosch_le kenneth: we're discussing about http://github.com/anb/ruote-kit/commit/c5f95b0f025b48ffa560b00d1aa1e9a15f394169
2010-02-11 11:31:58 utc kennethkalmer hey guys
2010-02-11 11:32:02 utc kennethkalmer was out in meetings earlier
2010-02-11 11:32:42 utc tosch_le we realized there should be some way to 'and' the search queries
2010-02-11 11:32:59 utc tosch_le (atm it's a plain 'or')
2010-02-11 11:34:26 utc kennethkalmer any suggestions
2010-02-11 11:35:16 utc kennethkalmer actually, can you gist me a log snippet so I can catch up ?
2010-02-11 11:35:17 utc tosch_le anb wrote:
2010-02-11 11:35:19 utc tosch_le "or" the participants, "and" for the fields
2010-02-11 11:35:21 utc tosch_le and "and" the total ?
2010-02-11 11:36:33 utc tosch_le gna, my irc client is eating the authors: http://gist.github.com/301441
2010-02-11 11:36:35 utc tosch_le me is starting, anb answering
2010-02-11 11:37:07 utc kennethkalmer catching up, thanks :)
2010-02-11 11:37:25 utc tosch_le np. i'm out for launch, sorry, will be back later.
2010-02-11 11:38:21 utc kennethkalmer np, have to eat too
2010-02-11 11:59:16 utc anb_ i'm back
2010-02-11 12:06:59 utc kennethkalmer hi anb_
2010-02-11 12:07:35 utc anb_ Hello
2010-02-11 12:07:56 utc kennethkalmer this search thing is tricky, and could a lot of issues if we don't manage it right
2010-02-11 12:08:20 utc kennethkalmer wondering if strictly OR isn't the best approach here
2010-02-11 12:08:26 utc kennethkalmer the client can also do some filtering
2010-02-11 12:08:35 utc kennethkalmer and the lookup requirements would be mostly client specific
2010-02-11 12:08:41 utc kennethkalmer (erm, project specific)
2010-02-11 12:09:37 utc kennethkalmer if any really advanced features are needed, the implementer can create their own storage participant and extend it to their liking
2010-02-11 12:10:19 utc kennethkalmer ruote-kit then expects the storage participants to implement certain methods, which are called for searching
2010-02-11 12:10:50 utc kennethkalmer the participant can then determine how to interpret the query and execute it according to it's own query plan
2010-02-11 12:18:08 utc anb_ it's indeed tricky
2010-02-11 12:18:48 utc anb_ at the moment storage has by_field and by_participant, so the addition of by_field does makes sense
2010-02-11 12:20:18 utc anb_ maybe the GET workitems should mirror the method sent to the participant to support future additions like GET /workitems?by_field[customer]=33
2010-02-11 12:20:42 utc anb_ or ?by_participant[toto]
2010-02-11 12:21:21 utc anb_ so if someone adds a by_mysearch it would support it from the start
2010-02-11 12:25:15 utc kennethkalmer that is another way
2010-02-11 12:25:33 utc kennethkalmer we can't just blindly use send(), so we'll need conventions
2010-02-11 12:27:45 utc anb_ it would be a nice security hole :)
2010-02-11 12:29:30 utc kennethkalmer :)
2010-02-11 12:37:51 utc tosch_le so we will do a strictly or and let the client do the reduce part
2010-02-11 12:39:00 utc anb_ it's your call guys
2010-02-11 12:39:56 utc tosch_le there could be a ALLOWED_QUERY_METHODS constant in the storage participant
2010-02-11 12:41:18 utc tosch_le (or a class variable or whatever to manage that)
2010-02-11 12:46:58 utc tosch_le or better: let the storage participant handle it all. just as idea:
2010-02-11 12:47:00 utc tosch_le class Ruote::StorageParticipant
2010-02-11 12:47:02 utc tosch_le def query( method, query_key, query_value )
2010-02-11 12:47:16 utc jmettraux by_field
2010-02-11 12:47:42 utc tosch_le method could be by_field, by_participant, by_foo
2010-02-11 12:48:00 utc jmettraux it's already implemented
2010-02-11 12:48:17 utc tosch_le ACTION knows
2010-02-11 12:48:25 utc jmettraux ok
2010-02-11 12:48:58 utc tosch_le we're thinking about ways to generalize the search query handling in rk's /workitems
2010-02-11 12:49:05 utc jmettraux ok
2010-02-11 12:49:29 utc jmettraux sorry, read too fast
2010-02-11 12:53:58 utc tosch_le quick hack: http://gist.github.com/301475
2010-02-11 12:54:18 utc tosch_le finder methods would have to be prefixed by "by_"
2010-02-11 12:54:38 utc tosch_le no need for ALLOWED_QUERY_METHODS then
2010-02-11 12:56:14 utc tosch_le ('resource' may be misleading, just couldn't think of a better name)
2010-02-11 12:56:47 utc jmettraux criterion
2010-02-11 12:59:36 utc tosch_le thanks, updated the gist
2010-02-11 13:01:39 utc anb_ why not call the by_ directly ? ruote-kit could check that it starts with by_ before calling
2010-02-11 13:03:05 utc jmettraux ACTION wonders what the ruote-kit team is trying to achieve
2010-02-11 13:04:24 utc tosch_le as the method would be in ruote's storage participant, rk won't be the only instance calling it. that's why i would add 'by_' inside the query method itself
2010-02-11 13:05:58 utc tosch_le jmettraux: rk should do /workitems?criterion1[arg1]=arg2&criterion1[arg1]&criterion3[arg1]=arg2&criterion3[arg2]=arg4
2010-02-11 13:06:30 utc jmettraux participant[hair_colour]=blue ?
2010-02-11 13:06:32 utc tosch_le rk user's shall be able to extend the storage participant with custom finder methods if needed
2010-02-11 13:06:59 utc tosch_le and use those custom finder methods without the need to change rk itself
2010-02-11 13:07:21 utc jmettraux ok
2010-02-11 13:08:18 utc jmettraux that means I will have to stick my fingers out and provide all sorts of way to query the storage participant
2010-02-11 13:08:45 utc jmettraux couch/fs/hash/dm
2010-02-11 13:09:02 utc jmettraux ...
2010-02-11 13:09:21 utc jmettraux a bit of history / perspective
2010-02-11 13:10:02 utc jmettraux initially ruote-rest, later ruote-kit were integrating a 'store' participant for convenience
2010-02-11 13:10:42 utc jmettraux maybe we shouldn't work too hard on querying workitems and let the storage exposed
2010-02-11 13:11:53 utc tosch_le but that's the approach behind it: just provide some basic finders with an unified interface and let the user implement his own if he needs them
2010-02-11 13:12:36 utc jmettraux but the user could also directly query couch or the rdbms
2010-02-11 13:13:45 utc jmettraux (that was anb_'s initially intention IIRC)
2010-02-11 13:14:01 utc jmettraux I would be OK with working on extending the StorageParticipant
2010-02-11 13:14:29 utc kennethkalmer my thoughts earlier too
2010-02-11 13:14:43 utc tosch_le hmm. it's some kind of the "one tool to rule them all" problem, i suppose ;-)
2010-02-11 13:15:21 utc kennethkalmer http://gist.github.com/301490
2010-02-11 13:15:28 utc kennethkalmer logs for when jmettraux & tosch_le were out
2010-02-11 13:15:51 utc jmettraux aaah
2010-02-11 13:16:04 utc tosch_le i've seen that. that's where my idea came from
2010-02-11 13:17:08 utc kennethkalmer just giving john some insight
2010-02-11 13:17:18 utc kennethkalmer i think the rk-bundled search should be minimal
2010-02-11 13:17:33 utc kennethkalmer enough to be useful, let the clients do multiple calls if needed
2010-02-11 13:17:41 utc tosch_le the fine thing on the query interface method: there would be no need to change the rest of the storage participant, by_wfid, by_participant, by_field could be used out of the box
2010-02-11 13:17:52 utc kennethkalmer yep
2010-02-11 13:18:14 utc kennethkalmer we need two things then
2010-02-11 13:18:20 utc kennethkalmer from criterion pov
2010-02-11 13:18:53 utc kennethkalmer by_criterion=arg1&by_criterion[key]=value
2010-02-11 13:19:05 utc kennethkalmer by_participant['foo'] kinda sucks
2010-02-11 13:19:18 utc kennethkalmer by_participant=foo,bar,widget is a bit easier
2010-02-11 13:19:32 utc kennethkalmer or pipes, depends on by_participant()
2010-02-11 13:19:38 utc jmettraux ?participant=a,b,c
2010-02-11 13:20:30 utc kennethkalmer i dig that too
2010-02-11 13:21:15 utc kennethkalmer just think of the -> store.send(:by_participant) if store.respond_to?(:by_participant) <-
2010-02-11 13:21:16 utc tosch_le if would handle the argument mapping in rk, so that criterion1=val1,val2,val3&criterion2[key1]=val1&criterion2[key2]=val1 should be ok
2010-02-11 13:21:29 utc kennethkalmer ignore last line
2010-02-11 13:21:36 utc kennethkalmer i'm torn guys
2010-02-11 13:21:51 utc tosch_le s/if/i/
2010-02-11 13:21:56 utc kennethkalmer we should have ?participant & ?field[key]=value
2010-02-11 13:22:10 utc tosch_le participant would be a criterion
2010-02-11 13:22:15 utc tosch_le field another
2010-02-11 13:22:32 utc kennethkalmer custom queries can be -> by_whatever
2010-02-11 13:23:00 utc tosch_le and whatever would be a criterion, too ;-)
2010-02-11 13:23:28 utc jmettraux if you guys want I can make participant a field
2010-02-11 13:23:39 utc kennethkalmer ah, you mean : params[:whatever] -> by_whatever()
2010-02-11 13:23:49 utc tosch_le yes.
2010-02-11 13:23:53 utc kennethkalmer jmettraux: lets argue this out in style first :)
2010-02-11 13:24:11 utc kennethkalmer s/argue/debate/
2010-02-11 13:26:46 utc tosch_le all i would like to see is an easily understand- and extendable query interface for the storage participant.
2010-02-11 13:26:48 utc tosch_le john, of course you're right, the user could query the storage by himself. but that's another interface he has to add to his app if he already uses rk. there is a workitem query method in rk, why should the user not be able to use it?
2010-02-11 13:27:17 utc tosch_le (with the full power his own storage participant provides)
2010-02-11 13:27:53 utc tosch_le there's no need for ruote itself to provide a wide range of by_whatever methods, the current ones are quite sufficient.
2010-02-11 13:28:04 utc jmettraux ok
2010-02-11 13:28:40 utc tosch_le but a unified interface to them would make it easy to add own finders and use them from within rk -- without the hassle of querying couch or whatever.
2010-02-11 13:29:33 utc tosch_le imho the user should have the chance that the storage is transparent for him
2010-02-11 13:30:15 utc jmettraux leaky abstraction maybe
2010-02-11 13:30:34 utc jmettraux does that mean that we should allow him to pass SQL queries ?
2010-02-11 13:30:46 utc jmettraux ActiveRecord and co do allow that
2010-02-11 13:31:57 utc jmettraux in a more BPMish context, there would be a tasklist, ie something managing workitems for humans
2010-02-11 13:32:07 utc jmettraux ruote[-kit] would just dispatch workitems to it
2010-02-11 13:32:22 utc jmettraux the tasklist would provide all sorts of bells and whistles
2010-02-11 13:32:46 utc jmettraux storageparticipant is a kind of "depot"
2010-02-11 13:33:07 utc jmettraux kind of rough
2010-02-11 13:33:24 utc jmettraux guys please don't overdo the query interface
2010-02-11 13:33:38 utc jmettraux look at couch doc, it's super inspiring
2010-02-11 13:34:07 utc jmettraux back to my BPMish task list
2010-02-11 13:34:23 utc jmettraux there would be all sorts of bells and whistle in it
2010-02-11 13:34:31 utc jmettraux delegation, ...
2010-02-11 13:34:49 utc jmettraux there could even be a small ruote running in it
2010-02-11 13:34:58 utc jmettraux in fact my barley example is a task list
2010-02-11 13:35:04 utc anb_ I have the feeling you're talking to me john :)
2010-02-11 13:35:15 utc jmettraux sorry
2010-02-11 13:35:23 utc jmettraux I was trying to emit my feeling before leaving
2010-02-11 13:35:30 utc jmettraux leaving you guys to the final decision
2010-02-11 13:35:40 utc anb_ but you're right about the task manager
2010-02-11 13:35:50 utc anb_ storage participant might be not enough
2010-02-11 13:36:39 utc jmettraux there is another thing : most of the time, you can query before storing
2010-02-11 13:36:53 utc jmettraux i.e. by_participant / by_store
2010-02-11 13:37:14 utc jmettraux by placing in a different participant/store you have already done most of the query work
2010-02-11 13:37:32 utc jmettraux ok
2010-02-11 13:37:38 utc jmettraux sorry guys, I'm getting old
2010-02-11 13:37:38 utc tosch_le i've no concern in overdoing the query thing. that's why i'm saying: let the user do it by himself.
2010-02-11 13:37:49 utc jmettraux ok
2010-02-11 13:37:50 utc tosch_le i suppose we agree on that.
2010-02-11 13:38:21 utc tosch_le the question: where should the user be able to do the querying by himself?
2010-02-11 13:38:46 utc jmettraux depends on the storage and the amount of data I guess
2010-02-11 13:39:22 utc jmettraux real store <--> ruote-kit <--> client side
2010-02-11 13:39:27 utc tosch_le i would give him the means to easily extend the storage participant to his own needs. of course, he could just collect all workitems from rk or even query the storage directly
2010-02-11 13:40:23 utc jmettraux the user could add "routes" for his views in ruote-kit
2010-02-11 13:40:36 utc tosch_le but the "add your finders to the storage participant" ways seems somehow elegant to me
2010-02-11 13:40:52 utc tosch_le s/ways/way/
2010-02-11 13:41:14 utc jmettraux I think I'm starting to get it
2010-02-11 13:41:55 utc tosch_le it even enables the user to switch the storage he uses if he changes his mind without needing to change the code
2010-02-11 13:42:44 utc jmettraux def method_missing (m, *args); if ma = m.to_s.match(/^find\_by\_(.+)$/)...
2010-02-11 13:44:47 utc tosch_le so that you could do storage_participant.criterion(arg1) ?
2010-02-11 13:45:34 utc jmettraux not sure
2010-02-11 13:45:38 utc jmettraux why not
2010-02-11 13:46:19 utc tosch_le i don't think there's a need for that. calling find_by_criterion is not that much more complicate ;-)
2010-02-11 13:47:21 utc tosch_le but i just realize def query is not necessary for rk to implement the same functionality. we can do that directly in rk
2010-02-11 13:47:38 utc jmettraux ok
2010-02-11 13:47:50 utc jmettraux maybe we should just focus on helping anb_
2010-02-11 13:48:00 utc jmettraux he is in direct need for it it seems
2010-02-11 13:48:15 utc jmettraux requirement driven
2010-02-11 13:48:52 utc anb_ that's nice but don't waste too much time on this
2010-02-11 13:48:53 utc tosch_le the starting point was the questions: should fields and participant querys for /workitems in rk be combined by 'and' or 'or'
2010-02-11 13:49:19 utc tosch_le in the end, we agreed on 'or' and client side filtering
2010-02-11 13:49:23 utc anb_ I'm not even sure what my requirements are exactly
2010-02-11 13:49:25 utc jmettraux HTTP has only AND
2010-02-11 13:50:31 utc tosch_le have a look at antoine's current implementation and you'll see what i mean with 'or': http://github.com/anb/ruote-kit/commit/c5f95b0f025b48ffa560b00d1aa1e9a15f394169
2010-02-11 13:52:38 utc jmettraux ok
2010-02-11 13:53:09 utc jmettraux I would stick with HTTP and have only AND
2010-02-11 13:53:48 utc jmettraux I think I will rewrite the query methods in StoreParticipant
2010-02-11 13:53:55 utc jmettraux now I understand
2010-02-11 13:54:06 utc jmettraux too much pain involved by the current implementation
2010-02-11 13:54:36 utc jmettraux ?participant=x&wifd=y&field1=y&field2=z
2010-02-11 13:54:41 utc jmettraux 1 method
2010-02-11 13:54:51 utc anb_ yes the "or" was easy to implement
2010-02-11 13:54:52 utc tosch_le yes, that's my point.
2010-02-11 13:54:58 utc jmettraux great
2010-02-11 13:55:53 utc jmettraux I would go for 'participant' and 'wfid', ignoring any field set to those names
2010-02-11 13:56:41 utc jmettraux but well
2010-02-11 13:56:46 utc jmettraux that is outside of my scope
2010-02-11 13:56:52 utc jmettraux it's your decision ;)
2010-02-11 13:57:04 utc jmettraux I will provide 1 method for wfid/part/fields
2010-02-11 13:57:14 utc jmettraux the ruote-kit iface is yours
2010-02-11 13:57:55 utc tosch_le great
2010-02-11 13:58:21 utc jmettraux cool, that's super-valuable feedback
2010-02-11 13:58:29 utc jmettraux many thanks !
2010-02-11 13:59:52 utc jmettraux if you have more/different requirements, please expose them on the ML
2010-02-11 13:59:56 utc jmettraux I'm out for now
2010-02-11 14:00:03 utc jmettraux thanks for your patience !
2010-02-11 14:00:04 utc tosch_le bye & good night
2010-02-11 14:00:09 utc jmettraux ciao !
2010-02-11 15:36:45 utc anb_ bye tosch_le, and thanks for all the thinking on this query thing :)
2010-02-11 15:37:25 utc tosch_le never mind. thanks for your input!
2010-02-11 15:37:29 utc tosch_le bye!
2010-02-11 21:27:09 utc MaL0 hi
2010-02-11 21:27:35 utc MaL0 what's exactly ruote for ?