Members present: julunggul, wastl, westei, jfrank, wikier ---------------- Meeting summary: ----------------
1. Preface 2. ldcache h. http://code.google.com/p/lmf/source/browse/#hg%2Fsesame%2Fsesame-filter (wastl, 2) 3. user management 4. hibernate 5. configuration service s. check list serialization changes on configuration-commons (wikier, 5) 6. versioning 7. stackable sails p. http://code.google.com/p/lmf/source/browse/lmf-ldcache/src/main/java/at/newmedialab/lmf/ldcache/services/ldcache/LDCacheSailProvider.java (wastl, 7) >. create an LMF component for the Sesame inferencer (wastl, 7) 8. impc report 9. ldp 10. jira n. check jira's workflow (wikier, 10) 11. aob k. fich components at jira (wikier, 11) -------- Actions: -------- - check list serialization changes on configuration-commons (wikier, 09:24:19) - create an LMF component for the Sesame inferencer (wastl, 09:39:19) - check jira's workflow (wikier, 09:48:57) - fich components at jira (wikier, 09:51:49) IRC log follows: # 1. Preface # 09:01:29 [wikier]: topics? 09:01:37 [wastl]: ok 09:01:59 [wastl]: topics: ldcache, hibernate, user management, config service, versioning :) 09:02:07 [wastl]: (most of them quick) 09:02:29 [wikier]: for me: impc report and ldp, mainly 09:02:37 [wastl]: aanother topic: stackable sails 09:02:45 [jfrank]: just briefly: jira 09:03:14 [wastl]: ok, let's start :) # 2. ldcache # 09:03:44 [wastl]: LDCache is now integrated again into the LMF components 09:03:52 [wastl]: works basically as before 09:03:59 [wastl]: but it is a bit more configurable 09:04:39 [wastl]: namely it is possible to configure the cache context (so we could close the JIRA issue) and it is more flexible to define what should be considered external and what not 09:04:59 [wastl]: - cache context is passed as parameter, I currently get it from contextService.getCacheContext() 09:04:59 [wikier]: aja 09:05:37 [wastl]: - deciding what is an external resource is now based on the ResourceFilter API that I introduced some months ago for the enhancer 09:05:59 [wastl]: #link http://code.google.com/p/lmf/source/browse/#hg%2Fsesame%2Fsesame-filter 09:06:30 [wastl]: I will today clean up the ldcache component a bit 09:06:39 [wastl]: otherwise the task is done 09:06:52 [wastl]: questions? 09:07:15 [wikier]: fine for me 09:07:22 [wikier]: next topic 09:07:22 [jfrank]: not yet... will arise with usage... 09:07:29 [wastl]: for sure 09:07:29 [wastl]: ok, so next topic :) # 3. user management # 09:08:02 [wastl]: I changed the user management so that it now stores all account information in the config file instead of the database 09:08:14 [wastl]: please check if everything is still working :) 09:08:22 [wikier]: passwords too? 09:08:25 [wastl]: as SHA1 hash 09:08:38 [wikier]: sure 09:08:44 [wikier]: ok 09:09:07 [jfrank]: did you keep my pwd-format from the db-implemetation? 09:09:14 [wastl]: yes 09:09:29 [jfrank]: because then you can reset a password in the config-file 09:09:30 [wastl]: the only thing is that the storage backend is no longer the database but the config file 09:09:37 [wastl]: yes you still can 09:09:44 [jfrank]: perfect 09:09:44 [wastl]: there are now two fields 09:09:52 [wastl]: user.X.password (for resetting) 09:10:22 [wastl]: user.X.pwhash (SHA1 hash of password) 09:10:52 [wastl]: the user.X.password field is only read for initialising users 09:10:59 [wastl]: but please check if this is still working as expected 09:11:29 [wikier]: ACTION adds user management to the list of things to check 09:11:37 [wikier]: supar 09:11:37 [wikier]: super 09:11:44 [wastl]: there is a reason why I did this change, which leads me to the next topic :) # 4. hibernate # 09:11:52 [wikier]: :) 09:12:07 [wastl]: all Hibernate dependencies have been completely removed now 09:12:14 [wastl]: the user management was the last component that used Hibernate 09:12:22 [julunggul]: how about unit test to prove functionality, you can use it even if the back. impl changes :) 09:12:37 [julunggul]: I mean unit test for user mng. 09:12:52 [wastl]: julunggul: there are many unit tests, but not everything is testable 09:12:59 [wastl]: in this case it is rather integration tests 09:13:07 [julunggul]: ok 09:13:14 [wastl]: the unit tests are working 09:13:29 [wastl]: integration tests still need to be written or adapted after the architecture changes 09:13:44 [julunggul]: reasonable 09:13:46 [wastl]: but back to Hibernate 09:13:59 [wastl]: there is no component that depends on Hibernate anymore 09:14:07 [wastl]: so I removed the dependency 09:14:32 [wastl]: but there might still be cases where "references" to Hibernate are left, e.g. the entities field in the kiwi-module.properties files 09:15:10 [wastl]: also, the PersistenceService is now just a stub that initialises the database, at some point this should be simplified (maybe merged with the SesameService) 09:15:44 [wastl]: I will clean up a bit, but if you also encounter something related to Hibernate/JPA then clean up :) 09:15:55 [wikier]: all simplifications of the init process I'm sure they will be useful 09:15:59 [wastl]: yes 09:16:07 [wastl]: the startup now is much faster 09:16:14 [wastl]: (my impression) 09:16:29 [wastl]: but we need to do some real comparison with a LMF 2.4 release 09:16:29 [wikier]: and probably less open to issues 09:16:44 [wastl]: I did some initial profiling with YourKit 09:17:07 [wastl]: most of the time is now spent in PostgreSQL 09:17:24 [wastl]: when importing 3100 triples (takes 5 seconds with PostgreSQL) 09:17:31 [wastl]: which is how it should be 09:17:44 [wastl]: with Hibernate, we spent most of the time actually in Hibernate 09:17:52 [wastl]: which is how it should not be :) 09:18:22 [wikier]: right 09:18:24 [wastl]: of the time spend in postgres, about 3 seconds are for inserting, and 2 seconds are for checking for existance 09:18:52 [wastl]: but this is all very preliminary, I will do more detailed profiling next week 09:19:29 [julunggul]: this was more or less predictable, JPA cuts the perf. and (if should give portability) 09:20:01 [wastl]: our portability currently covers PostgreSQL, MySQL, H2, and Oracle is on the list 09:20:09 [wastl]: but this is for later 09:20:22 [julunggul]: reasonable, again :) 09:20:43 [wastl]: but anyways: main message again: please verify if it is working and clean up 09:20:57 [wastl]: further questions? :) 09:20:59 [wikier]: all ;-) # 5. configuration service # 09:21:19 [wastl]: here I have a question :) 09:21:36 [wastl]: the configuration service now seems to store list configurations by repeating the same key with different values 09:21:42 [wastl]: is this correct and working properly? 09:22:12 [wikier]: you mean, for lists of values? 09:22:15 [wastl]: yes 09:22:20 [wastl]: for example, I now have 09:22:22 [wikier]: afaik not 09:22:35 [wastl]: user.admin.roles = editor 09:22:36 [wastl]: user.admin.roles = manager 09:22:36 [wastl]: user.admin.roles = user 09:22:36 [wikier]: but maybe they changed how lists are serialized... no idea 09:22:45 [wastl]: Jakob? 09:23:12 [jfrank]: did't change anything in storing values 09:23:12 [wastl]: no, commons-configuration was not changed, but Jakob did some changes 09:23:20 [wastl]: hmm 09:23:27 [wikier]: wastl: does it correctly parse back into lists? 09:23:49 [wastl]: did not try really, because I clean my configuration on start 09:23:52 [wastl]: but I can check 09:24:19 [wikier]: #action check list serialization changes on configuration-commons 09:24:27 [wikier]: ok 09:24:34 [wastl]: but it is not related to the FallbackConfiguration you introduced? 09:25:19 [wikier]: should not 09:25:36 [jfrank]: it just overrieds the getList method 09:25:49 [wastl]: I am referring to this revision 09:25:49 [wastl]: http://code.google.com/p/lmf/source/detail?r=f2cd57a4a29d87659fa56bb315d9cb99eb2e0f68&path=/lmf-core/src/main/java/kiwi/core/services/config/ConfigurationServiceImpl.java 09:26:20 [wastl]: ok, we will simply test and hope the best :) 09:26:42 [wastl]: next topic? 09:26:42 [wastl]: I have # 6. versioning # 09:27:19 [wastl]: this will be my task until tomorrow, to integrate the LMF versioning module again 09:27:42 [wastl]: tomorrow maybe Thomas can revise the webservices as well 09:27:49 [wastl]: topic end :) 09:27:58 [wikier]: :-) # 7. stackable sails # 09:28:19 [wastl]: ok, how to explain 09:28:49 [wastl]: since now the whole repository builds on a Sesame Stack, additional functionality is added to the repository through Stackable Sails 09:29:04 [wastl]: which wrap other Sails and can add more functionality 09:29:19 [wastl]: for example, both versioning and LDCache are implemented in that way 09:29:49 [wastl]: but we would like to still remain flexible and keep versioning and LDCache in separate modules that can be disabled 09:30:15 [wastl]: therefore, I added a new service architecture that allows modules to provide their stacks to wrap 09:30:34 [wastl]: there are three interfaces: 09:30:57 [wastl]: - TransactionalSailProvider: allows sails that make use of the KiWi transaction data 09:31:19 [wastl]: - NotifyingSailProvider: allows sails that make use of the notifications sent on triple add/remove (lower level than transactions) 09:31:28 [wastl]: - StandardSailProvider: allows any sails to be wrapped 09:31:57 [wastl]: all interfaces provide a single method: public SailWrapper createSail(Sail parent); 09:32:12 [wastl]: (with different return and parameter types) 09:32:29 [wastl]: on initialization (or re-initialization), the Sesame Service injects all such providers 09:32:57 [wastl]: and wraps the respective sails around the main sail in proper order (first transactional, then notifying, then standard) 09:33:04 [wastl]: as an example, have a look at 09:33:42 [wastl]: #link http://code.google.com/p/lmf/source/browse/lmf-ldcache/src/main/java/at/newmedialab/lmf/ldcache/services/ldcache/LDCacheSailProvider.java 09:33:58 [wastl]: this is very flexible and very simple 09:34:19 [wastl]: and in principle it allows us now to exchange the triplestore backend 09:34:49 [wastl]: almost, because I need to extend the principle with providers that only work for KiWi-based repositories (like versioning) 09:35:12 [wastl]: I will do the same with versioning and later with the reasoner and the native SPARQL 09:35:21 [wastl]: topic end, questions? 09:36:29 [wastl]: so then next one with topics :) 09:36:34 [julunggul]: how do you pull/push the features to the sail ? are this features plugable ? 09:36:50 [wastl]: a Sail provides the features 09:37:04 [wastl]: the only problem is dynamically building the sail stack 09:37:12 [wastl]: and now this is pluggable 09:37:36 [julunggul]: so there will be diff. sails ? 09:37:44 [wastl]: there are now Sails for versioning, for LDCache, for transaction support 09:37:57 [wastl]: I am working on Sails for reasoning and for native SPARQLÃ 09:38:06 [wastl]: and Sesame also provides some 09:38:19 [wastl]: e.g. the Sesame built-in inferencer 09:38:29 [wastl]: which can be used as an alternative reasoner 09:38:43 [wikier]: cool 09:39:04 [wastl]: actually, I could make another lmf component for the Sesame inferencer :) 09:39:04 [julunggul]: reasonable cool, I agree :D 09:39:19 [wastl]: #action create an LMF component for the Sesame inferencer 09:39:27 [wikier]: wastl: you mean for the mid-term? 09:39:27 [jfrank]: how is configuration done? via config-settings or availability in the classpath 09:39:29 [wikier]: ok, no xD 09:39:44 [wastl]: wikier: this is very easy and quick, takes only 1 hour 09:39:57 [wikier]: ok 09:39:57 [wastl]: jfrank: can be both 09:39:57 [wikier]: xD 09:40:04 [wastl]: the components in the end decide 09:40:12 [wastl]: I can do something like this in the createSail() 09:40:34 [wastl]: if(enabled) { return new XYSail(parent) } else { return parent } 09:41:43 [wastl]: I will polish the components that use it a bit and then you'll see 09:41:57 [wastl]: there is also the issue that if the component configuration changes 09:41:57 [jfrank]: ok, fine 09:42:04 [wastl]: it would sometimes be necessary to rebuild the stack 09:42:19 [julunggul]: This(chose the sail) can be solve in the client, somehow transparent to the user. Can this create side effects ? I mean using diff. sails in the same time ? 09:42:21 [wastl]: not sure yet how to solve it, but probably reinitlaizing the repository 09:42:42 [wastl]: julunggul: no, this is backend configuration 09:43:19 [wastl]: but in the long term there could be different backend configurations for different system instances in a single JVM, but this will be the OSGi architecture then 09:43:27 [wastl]: not to discuss now :) 09:43:29 [wikier]: +1 09:43:34 [julunggul]: ok 09:43:49 [wastl]: ok, wikier, you had some topics # 8. impc report # 09:43:58 [wikier]: basically 09:44:05 [wikier]: draft at dev@ 09:44:12 [wastl]: yes, saw it 09:44:12 [wastl]: +1 09:44:19 [wikier]: not so important # 9. ldp # 09:44:34 [wastl]: question is for me now who is responsible for the impc reports 09:44:57 [wikier]: the marmotta pmc 09:45:04 [wikier]: so us 09:45:12 [wikier]: with our mentors 09:45:27 [wikier]: not a big deal 09:45:27 [wastl]: ok 09:45:29 [wikier]: ldp 09:45:34 [wikier]: looks that we are arrivint to some agreements at the wg 09:45:49 [wikier]: tomorrow I'll push some nw ideas about its impmplementation 09:45:59 [wikier]: and that's it from my side 09:46:04 [wastl]: +1 09:46:12 [wastl]: so tomorrow is telco? 09:46:14 [wikier]: no 09:46:19 [wikier]: Mondays 09:46:27 [wikier]: push code 09:46:34 [jfrank]: +1 09:46:34 [wikier]: and Monday discuss it 09:46:34 [wastl]: ok :) 09:46:37 [wikier]: xD # 10. jira # 09:46:51 [wikier]: jfrank? 09:47:21 [jfrank]: i found many issues marked as "resolved" - who will actually close them? 09:47:34 [wastl]: hmm, this is a question of the workflow 09:47:42 [westei]: this is done during the release process 09:47:44 [wastl]: not sure how the workflow should actually be 09:47:49 [wastl]: ok 09:48:05 [jfrank]: so whoever is fixing an issue should not close it at the end? 09:48:12 [wastl]: no, only resolve it 09:48:34 [wikier]: so resolve + close? 09:48:42 [julunggul]: Resolved most be validated by a tester and then closed. 09:48:45 [wikier]: maybe we can do that as a single step in the workflow 09:48:49 [wikier]: I'll check it 09:48:51 [julunggul]: at least in theory 09:48:57 [wikier]: #action check jira's workflow 09:49:12 [jfrank]: you can directly close an issue 09:49:12 [westei]: issues that are not related to releases (e.g. homepage related issues) should be closed immediately 09:49:21 [wikier]: I think if the reporter is not the same that who solve it, then the reported has to close it 09:49:42 [wikier]: reporter 09:49:44 [wikier]: I'll check it 09:50:00 [westei]: ask Fabian he should know the details 09:50:04 [wikier]: ok 09:50:12 [wikier]: I'll ask him # 11. aob # 09:50:19 [wastl]: the reporter will often be outside the developer group 09:50:19 [wikier]: aob? 09:50:34 [jfrank]: another jira thing 09:50:42 [jfrank]: components 09:50:59 [jfrank]: they do not reflect the structure of the project 09:51:19 [wastl]: not completely 09:51:27 [wikier]: more or less it aims to do it 09:51:27 [wastl]: we should maybe sit together and decide on the components 09:51:42 [wikier]: that's why I send it to the mailing list 09:51:45 [wastl]: yes, but some are missing 09:51:49 [wikier]: #action fich components at jira 09:51:50 [wikier]: fix 09:51:51 [jfrank]: well: wiki, ldpath, ldclient, ... where should they go? 09:51:59 [wastl]: triplestore 09:52:04 [wikier]: maybe... 09:52:05 [wikier]: more fie grained 09:52:12 [wikier]: I see th epoint 09:52:13 [wikier]: the point 09:52:14 [wikier]: ok 09:52:28 [wikier]: anything else? I have to leave 09:52:42 [jfrank]: not from my side
