13:49:09 <emmanuel> #startmeeting
13:49:09 <jbott> Meeting started Tue May 27 13:49:09 2014 UTC.  The chair is emmanuel. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:49:09 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:49:12 <sannegrinovero> seems bot is not caps-lock safe
13:49:27 <emmanuel> alright
13:49:47 <emmanuel> So I ahve been catching up on a lot of architecture discussions
13:49:59 <emmanuel> which is good but it also mean I did not spend a lot on OGM / Search per se
13:50:17 <emmanuel> But so you know it involves the idea of a datasource like stuff for WildFly
13:50:25 <emmanuel> (to share connections across apps)
13:50:28 <emmanuel> in a ii env
13:50:30 <emmanuel> ee
13:50:49 <sannegrinovero> interesting, did you also propose a data-source like deployment of an Infinispan Cache?
13:50:52 <emmanuel> and also some CDI extension related to that to make things simple to use
13:51:12 <emmanuel> sannegrinovero: no it idd not occur to me but that could definitely be doable
13:51:27 <sannegrinovero> that used to be high on our wish list as Infinispan users
13:51:30 <emmanuel> but it requires WF / Infinispan talking via hotrod
13:51:49 <sannegrinovero> editing the core WF configuration file is not as nice as providing a conf file
13:51:57 <emmanuel> BTW why do you need it for Ispn?
13:52:00 <emmanuel> not to cache conenctions
13:52:04 <sannegrinovero> hotrod? not thought of that
13:52:08 <emmanuel> is that to share CacheManager configs?
13:52:18 <sannegrinovero> yes, to share CacheManager configs across apps
13:52:29 <emmanuel> and share classloader and boom ;)
13:52:31 <sannegrinovero> (or even just in a single app)
13:53:07 <emmanuel> Anyways you will hear from this as soon as I manage to get this project started
13:53:17 <sannegrinovero> well even just in a single app, using FORK people will want to reuse the single JGroups channel which wires up the different application server instances
13:53:21 <sannegrinovero> ok
13:53:27 <emmanuel> I want it simple and useful as a first step, nothing fancy
13:53:41 <sannegrinovero> that's what our intention with FORK was ;)
13:54:05 <sannegrinovero> especially useful for OGM (datastore) or Search (index store)
13:54:35 <emmanuel> what you describe is bery uuseful for ops
13:54:43 <emmanuel> less for devs, am I reading it correctly?
13:55:24 <sannegrinovero> well as a dev, it's damn hard to understand how to configure a Cache
13:56:08 <emmanuel> ok but that's Infinispan's problem
13:56:20 <emmanuel> It's easy to access a MongoDB DB
13:56:26 <sannegrinovero> dropping a single descriptor file - copy paste from our wiki or even self-generated via some project generator tool would be easier
13:56:28 <emmanuel> same for Neo4J
13:56:36 <emmanuel> it's all URL based
13:56:44 <emmanuel> Infinispan needs something like that
13:56:55 <sannegrinovero> right, it's something I expected the Infinispan team to deal with but needs WildFly architecture
13:57:31 <sannegrinovero> as its configuration, CacheManager, management and jgroups channels are managed by WF
13:57:43 <emmanuel> I also +1'ed gmorling and DavideD for their released and booed search for their non-release and that's all I did basicaly ;)
13:58:00 <gmorling> hehe
13:58:14 <gmorling> it was nice to see all this retweeting going on
13:58:33 <sannegrinovero> emmanuel: WDYM? Search was released past week
13:59:36 <emmanuel> I am off Thu and Fri but my plan is to keep working on these archtectural subjects + this datasource idea + whatever urgent comes up.
13:59:45 <emmanuel> sannegrinovero: oh apologies :(
14:00:05 <emmanuel> Not sure why my brain black that one out :/
14:00:10 <emmanuel> blacked
14:00:21 <sannegrinovero> emmanuel: admittedly late on schedule, so booing is partially accepted ;)
14:01:27 <emmanuel> sannegrinovero: interesting to see http://sourceforge.net/projects/hibernate/files/hibernate-search/
14:01:46 <emmanuel> 4.4.3 was barely downloaded
14:01:53 <emmanuel> 4.5 had the most
14:02:29 <emmanuel> anyways sorry for the side track
14:02:36 <sannegrinovero> 4.4.3 is very recent, 4.5 was released before that
14:02:58 <emmanuel> That's all for me. As usual, I'll try and help whoever needs help on PR or otherwise
14:03:01 <sannegrinovero> and I expect new downloaders going for 4.5
14:03:47 <emmanuel> sannegrinovero: the stage is for you
14:03:58 <sannegrinovero> ok
14:04:24 <sannegrinovero> I need to reassess priorities on Search, we did quite some work since the last JIRA review
14:04:54 <sannegrinovero> we're approx. 2 weeks late on schedule.. not too bad, but many big tasks are still rather undefined in terms of specifics
14:05:25 <sannegrinovero> which is a bit worrying as I was expecting some more research to happen in parallel which didn't happen yet
14:05:46 <sannegrinovero> I rebased my branch updating Infinispan to Search5
14:06:06 <sannegrinovero> and am still in trouble with the clustered queries, that's a complex one.
14:06:44 <sannegrinovero> I feel like I need to find *some* solution to move on, as I need the new 2,5 people in Infinispan to give us feedback on the new SPI and move on
14:06:46 <emmanuel> sannegrinovero: the experiment one?
14:06:56 <sannegrinovero> rather than keep maintaining the workarounds on current SPI
14:07:04 <sannegrinovero> yes the GSOC experimental feature
14:07:27 <emmanuel> It feels like it costs you 2 days every release to maintain
14:07:56 <emmanuel> if that's somewhat accurate, is it not worth it
14:08:03 <emmanuel> s/not//
14:08:04 <sannegrinovero> well any Lucene change costs me several days when things break.. unusual?
14:08:29 <sannegrinovero> So on paper this feature is great as it would mean no need for a shared index, so no need for a master/slave setup
14:08:43 <sannegrinovero> and also to be able to scale up on write operations
14:09:15 <sannegrinovero> in other words, I think we'd need it in future. Question is if it's too soon to spend maintenance time on it.
14:09:59 <sannegrinovero> #topic OGM using Search 5
14:10:24 <sannegrinovero> Having seen the roadmap of OGM.. I'll ask this again :) I think it's doable?
14:11:20 <gmorling> sannegrinovero: it depends on when you're done with 5 :)
14:12:02 <sannegrinovero> you aren't literally waiting for me right? As discussed previously, there is at least one task we planned for sake of OGM users which needs more details to be delivered.
14:12:09 <emmanuel> My understanding is that the cost of staying of 4 is fairly limited. And the main feature is the FIND_BY_ID automatic setting which does not require much testing
14:12:29 <gmorling> sannegrinovero: no, i'm not waiting
14:12:29 <emmanuel> sannegrinovero: what details?
14:12:51 <gmorling> my concern is that we may depend on a non-final version
14:13:00 <sannegrinovero> emmanuel: ok to stay in 4, but I'm not understanding how exactly OGM is supposed to "reconfigure" the default Search behaviour.
14:13:15 <emmanuel> it won't if 5 does not make the cut
14:13:42 <gmorling> tbh. i don't feel that this is a huge issue
14:13:53 <gmorling> its not nice
14:14:00 <gmorling> and it would be better if it worked out of the box
14:14:16 <gmorling> but it isnt a general issue which is in the way of using the stuff
14:14:16 <sannegrinovero> the issue is just a usability one. I'm more concerned on having mixed versions on classpaths since other libraries are moving on (Infinispan)
14:14:40 <emmanuel> note that it will also imply that OGM final goes with Infinispan 7.0 for which I don't know the dates and stability level
14:15:22 <sannegrinovero> Infinispan 7 is much more reliable than previous versions; the gotcha is the configuration files are different, but once you migrated such things its better.
14:15:22 <gmorling> hsearch 5 only supports ispn 7?
14:15:26 <sannegrinovero> gmorling: yes
14:15:40 <sannegrinovero> someone has to make a leap of fate and upgrade
14:15:44 <gmorling> so once 7 is there, should we support both, 6 and 7?
14:15:47 <gmorling> or only 7?
14:15:54 <sannegrinovero> well 6 is what you have in WF
14:16:01 <sannegrinovero> other than that, there are no reasons to stick on 6
14:16:26 <emmanuel> We can revisit this subject at the team meeting
14:16:36 <sannegrinovero> to the contrary, if you ever need any new feature (think hotrod) from Infinispan, you won't get it in Infinispan 6
14:16:41 <sannegrinovero> ok
14:16:41 <gmorling> this remote support use case, targets this 7 only?
14:16:58 <emmanuel> we will ahve 1 month of feedback and I don't see any urgency till then
14:16:59 <sannegrinovero> anything new is 7 only of course
14:17:34 <gmorling> so hot rod is in 7 only?
14:17:47 <sannegrinovero> emmanuel: the urgency I see is that I think we should at least have POC branches to make sure it's going to work
14:17:47 <emmanuel> no but improvement on hot rod would
14:18:27 <emmanuel> it being Search and OGM or Infinispan and OGM
14:18:30 <emmanuel> ?
14:18:31 <sannegrinovero> gmorling: there is a specification of the protocol which is not allowed to change often. Version 2.0 of the protocol is being cast in stone now, and I don't expect it to change again in years.
14:18:49 <sannegrinovero> well both, but of course we've much more flexibility on Search
14:19:11 <sannegrinovero> it's just that early feedback is cheaper to address
14:19:36 <gmorling> but isnt DavideD working on this POC anyways?
14:19:41 <emmanuel> #action gmorling or DavideD to test an experimental branch using Hsearch 5 and Infinispan 7. Leaving out of master for now
14:19:52 <sannegrinovero> I could do the OGM upgrade to Search 5 in a branch myself, should be easy and get me the level of info I need.
14:20:02 <sannegrinovero> ah, better :) +1
14:20:23 <DavideD> gmorling, what I did was discussing with Mircea about it and we talked about an API to develop
14:20:25 <sannegrinovero> and I agree, no need for merging.
14:21:03 <gmorling> i had started with hsearch 5 recently
14:21:06 <sannegrinovero> thanks that's all from me
14:21:11 <gmorling> than i ran into the ispn version conflict
14:21:16 <gmorling> thats where i stopped
14:21:21 <DavideD> gmorling, Mircea also changed the code in a branach so that I could start the development, but then several other things popped out and I didn't have the time
14:21:29 <gmorling> i can continue and have a look how it integrates with 7
14:21:47 <gmorling> but this alone wont give any feedback on the suitability of the hot rod stuff for our purposes
14:22:01 <gmorling> DavideD: i see
14:22:13 <sannegrinovero> gmorling: the only complexity I expect is the configuration files are in a different format (and no backwards compatibility)
14:22:35 <gmorling> sannegrinovero: i see
14:22:36 <DavideD> the issue is not only hotrod but the Grouping API that it is missing a few methods that we would need for the integration
14:23:21 <gmorling> and we'd only support ispn 7 once we did the update?
14:23:39 <gmorling> so the remote dialect could take benefit of all possible improvements in 7?
14:23:45 <emmanuel> #action DavideD to remind and push for the necessary chnges required by OGM in Infinispan 7 (ML)
14:24:57 <emmanuel> sannegrinovero: anything else? Or cna you leave the stage to gmorling
14:25:07 <emmanuel> trying to meet the 20 mins deadline :)
14:25:28 <sannegrinovero> I already dropped the word :) gmorling go ahead
14:25:34 <gmorling> ok
14:26:00 <gmorling> so after that release last week which gave nice feedback in the neo4j community, i continued with OGM-513
14:26:00 <jbossbot> jira [OGM-513] Re-consider how native queries are expressed for MongoDB [Open (Unresolved) Improvement, Major, Gunnar Morling] https://hibernate.atlassian.net/browse/OGM-513
14:26:07 <sannegrinovero> #topic gmorling
14:26:22 <gmorling> which will allow more powerful native queries for mngodb
14:26:36 <gmorling> and at some point update native queries
14:26:51 <gmorling> apart from that i've finally sat down and created that roadmap proposal you all saw
14:27:30 <gmorling> as said in my mail, i'm unsure whether the three currently planned beta cycles will be sufficient
14:27:41 <gmorling> but i think its in a more overlookable and plannable stage now
14:28:40 <gmorling> i guess you need some time to digest that stuff?
14:29:38 <emmanuel> gmorling: stuff being? the roadmap document?
14:29:43 <gmorling> emmanuel: yes
14:29:59 <emmanuel> TBH I forgot where this doc is :)
14:30:04 <gmorling> gee
14:30:13 <gmorling> i sent you the link via email
14:30:23 <emmanuel> you sent me a 100 emails today
14:30:31 <emmanuel> at least
14:30:32 <gmorling> :)
14:30:47 <gmorling> there is a corralation between all these mails and the roadmap document
14:31:09 <emmanuel> anyways if you culd send it again that'd be ueful
14:31:22 <emmanuel> #action email to provide feedback ont he OGM roadmap with date
14:31:31 <gmorling> emmanuel: re-send the email you mean?
14:31:53 <jhalliday> emmanuel: got a minute to discuss ogm association support?
14:31:56 <emmanuel> yes or the link
14:32:12 <gmorling> emmanuel: https://docs.google.com/document/d/1R284IDaQ1SarLeYmyp5Jm-1SOOhFUC2mIEtEbSxA7Tg
14:32:46 <emmanuel> jhalliday: there are two back to back meetings on IRC, can we do that after? (in ~ 1h and 10 mins?
14:33:03 <emmanuel> because that's more than a minute usually :)
14:33:53 <jhalliday> hehe. I'll grab you tomorrow, don't think you'll be in such useful shape after 2hrs of meetings :-)
14:34:03 <emmanuel> k
14:34:13 <gmorling> thats it really from my side; continuing with 513
14:34:31 <gmorling> also will be offline for the last two days of this week
14:34:32 <emmanuel> gmorling: I'll give you feedback
14:34:39 <gmorling> emmanuel: thanks!
14:34:52 <emmanuel> DavideD: up on stage
14:35:04 <gmorling> you got 9 minutes :)
14:35:24 <DavideD> I've worked on the Neo4j integration, fixing the remarks in the pull request
14:36:26 <DavideD> This week I'm planning to fix the remaining things like generation of sequences, OneToOne relationship and the documentation
14:36:43 <DavideD> There are also verious caches to add in the code
14:37:57 <emmanuel> DavideD: stop playing starcraft in the roadmap document
14:38:08 <emmanuel> your cursor is moving at 120 APM
14:38:14 <gmorling> there are quite a few issues related to neo4j in beta4; i hope they all make sense, DavideD
14:38:32 <gmorling> the relationship stuff seems most important
14:38:33 <DavideD> gmorling, yes, most of them should be easy
14:38:39 <gmorling> as it affects the persistent format
14:38:49 <emmanuel> gmorling: question, are the most important features generally in the earlier betas?
14:38:53 <DavideD> some of them requires to add some metadata to the association
14:39:21 <emmanuel> i.e. if we need to drop things (and we will likely need to), will the most important bits be done
14:39:37 <gmorling> emmanuel: not consistently; some are a bit later as we e.g. need to wait for the orm update to 4.3.6
14:39:51 <emmanuel> sure
14:39:59 <gmorling> and its a bit clustered by topic, e.g. beta4 has a lot about neo4j
14:40:02 <emmanuel> Iw as asking for the general trend
14:40:25 <gmorling> but i can try and move less important ones more to the later cycles
14:42:16 <emmanuel> Neo4J takes a lot more energy than I wuld have anticipated
14:42:40 <gmorling> i think all dialects do, once you get into it
14:42:46 <gmorling> it has been the same with couchdb
14:42:58 <DavideD> Agree, implementing a dialect is not as easy as it seems
14:45:24 <emmanuel> Alright anything else?
14:45:33 <gmorling> not here
14:45:47 <emmanuel> Make sure to keep an eye on these roadmaps + dates to keep you honest on progress
14:46:29 <emmanuel> I say you not because I need it but rather because I don't feel I produce much on these topics nowadays ;)
14:47:04 <gmorling> yes, it's good to have this one finally
14:47:06 <sebersole> do we need an orm meeting today?
14:47:07 <emmanuel> sannegrinovero: one key stuff to unlock I think is the free-form PoC(s) you need.
14:47:27 <emmanuel> After that you will be able to distribute tasks to hardy and me
14:47:34 <emmanuel> #endmeeting