Summary of IRC meeting in #apachemarmotta, Thu Jan 24 09:08:24 2013

[ASF IRC Services <as...@wilderness.apache.org>]

Members present: westei, tkurz, sschaffert, jfrank, wikier

----------------
Meeting summary:
----------------

1. Preface

2. ldclient
  j. sschaffert writes until tonight tests for the linked data client modules (sschaffert, 2)
  >. open a Jira issue for providing the ldclient library as a separate Java library (sschaffert, 2)

3. ldcache

4. admin ui

5. user management

6. branding

7. branding
  t. call for logo requirements (wikier, 7)

8. user management

9. search

10. aob
  m. https://code.google.com/p/lmf/issues/list (wikier, 10)


--------
Actions:
--------
- sschaffert writes until tonight tests for the linked data client modules (sschaffert, 09:11:45)
- open a Jira issue for providing the ldclient library as a separate Java library (sschaffert, 09:15:44)
- call for logo requirements (wikier, 09:30:35)

IRC log follows:


# 1. Preface #
09:08:29 [wikier]: ok, let's start
09:08:30 [sschaffert]: my topics: ldclient, ldcache
09:08:31 [wikier]: topics?
09:08:44 [wikier]: also admin ui
09:08:54 [sschaffert]: branding
09:08:55 [wikier]: branding
09:08:59 [wikier]: yes
09:08:59 [sschaffert]: (your mail)
09:09:07 [jfrank]: search
09:09:10 [wikier]: ok
09:09:14 [tkurz]: user moudle
09:09:37 [wikier]: sschaffert: start with the libs
09:09:37 [sschaffert]: ok, enough for 20 minutes:)


# 2. ldclient #
09:10:14 [sschaffert]: so what I have finished yesterday night is moving out all linked data client functionality into a separate package
09:10:22 [sschaffert]: well, many packages
09:10:23 [sschaffert]: very modular
09:10:30 [sschaffert]: there is
09:10:44 [sschaffert]: ldclient-api, ldclient-core, and ldclient-provider-X
09:11:01 [sschaffert]: where X implements the provider for a certain kind of data, e.g. rdf, youtube, vimeo, mediawiki
09:11:07 [sschaffert]: and so on
09:11:14 [sschaffert]: I have moved all old implementations to the new architecture
09:11:24 [sschaffert]: work for today:
09:11:45 [sschaffert]: #action sschaffert writes until tonight tests for the linked data client modules
09:12:29 [sschaffert]: tomorrow I will do the same with the caching components of lmf-ldcache
09:12:29 [sschaffert]: I hope it only takes one day
09:12:39 [sschaffert]: and then everything can be integrated on Monday
09:12:44 [wikier]: so many artifacts right now xD
09:12:59 [sschaffert]: yes, this is a certain dilemma
09:13:14 [sschaffert]: flexibility vs. number of artifacts
09:13:29 [westei]: flexibility > number of artifacts
09:13:37 [wikier]: imo not a big issue
09:13:44 [sschaffert]: no, not with maven
09:13:45 [sschaffert]: I was just concerned that
09:13:52 [wikier]: just needs proper documentation and build management
09:14:00 [sschaffert]: the ldclient library could also be interesting for people not yet using Maven
09:14:22 [westei]: you can provide a ldclient-all jar
09:14:22 [sschaffert]: and there should be a kind of packaging for them where they simply use the ldclient library as a single jar
09:14:37 [sschaffert]: westei: yes and no
09:14:37 [sschaffert]: yes for the code
09:14:44 [sschaffert]: problem is the java services
09:14:52 [sschaffert]: because these files need to be merged somehow
09:15:00 [sschaffert]: so the META-INF/services
09:15:07 [westei]: thats easy
09:15:22 [westei]: you can do that with a maven assembly descriptor
09:15:23 [sschaffert]: but this is for another day, we should just keep it in mind (maybe make a Jira issue)
09:15:44 [sschaffert]: #action open a Jira issue for providing the ldclient library as a separate Java library
09:16:07 [sschaffert]: another short disclaimer:
09:16:07 [wikier]: I don see it as a priority right now
09:16:22 [wikier]: something for the future, I agree, but not a priority
09:16:39 [sschaffert]: yes, but it is the "last step" for community adoption, otherwise we will get stuck in the problem of all OSGi-based frameworks
09:16:44 [wikier]: the priority is the last release
09:16:44 [jfrank]: maybe for 3.5
09:16:45 [sschaffert]: only experts
09:17:07 [wikier]: I agree
09:17:22 [wikier]: but let's put in "something it'd be nice to have"
09:17:29 [sschaffert]: I would like to have usability / easy deployment of our technologies as a "key performance indicator" :)
09:17:37 [wikier]: right
09:17:44 [wikier]: but step by step
09:17:46 [sschaffert]: yes
09:17:52 [sschaffert]: ok, let me add the disclaimer
09:17:54 [wikier]: we could do it for the first marmotta release
09:18:14 [sschaffert]: I realised it will not be so easy to use other data models than Sesame as a backend for the ldclient
09:18:29 [sschaffert]: the reason is mainly that most data providers involve parsing
09:18:37 [sschaffert]: one way or the other
09:18:47 [sschaffert]: and as soon as you need a parser you are bound to a framework
09:19:08 [sschaffert]: so to make the client framework independent requires much more thinking
09:19:14 [sschaffert]: it is not as easy as with ldpath
09:19:37 [sschaffert]: and that's it, not a priority for now anyways
09:19:44 [sschaffert]: I will today write the tests for the different functionalities
09:20:02 [sschaffert]: and then the ldclient library can be used even outside the LMF to access any resources it supports
09:20:07 [wikier]: ok


# 3. ldcache #
09:20:22 [wikier]: yes, the goal is quite clear
09:20:37 [sschaffert]: not much to be said
09:20:46 [sschaffert]: I will start doing the same with the caching functionality tomorrow
09:20:52 [sschaffert]: and hope to finish it also tomorrow
09:20:59 [sschaffert]: as discussed in the last meetings
09:21:01 [wikier]: ok
09:21:22 [sschaffert]: goal is to be able to use it independently of the LMF
09:21:37 [sschaffert]: for now stacking it into a Sesame SAIL stack
09:21:52 [sschaffert]: and that's it
09:21:55 [wikier]: good
09:22:14 [wikier]: tkurz: proceed with your ui-related topics
09:22:16 [sschaffert]: in the end, we will have a modular system of ldclient, ldcache, ldpath that can be combined via Sesame SAILs as needed
09:22:22 [sschaffert]: yes
09:22:22 [sschaffert]: I am done


# 4. admin ui #
09:22:29 [wikier]: time runs....
09:22:45 [tkurz]: I finished the admin ui for the core module
09:23:14 [tkurz]: now I will reset the layout for all the other modules
09:23:29 [tkurz]: that's it ;)
09:23:38 [wikier]: I like the new style
09:23:40 [wikier]: but...
09:23:59 [wikier]: do we want to completely loose the SW colors?
09:24:14 [tkurz]: mhh. in the lmf they are in the logo
09:24:44 [tkurz]: and the colors are not good for layouting a whole page
09:24:53 [wikier]: maybe not so important
09:24:54 [wikier]: ok
09:25:02 [tkurz]: maybe we can add the cube somewhere?
09:25:07 [sschaffert]: maybe it would not be so bad to adopt the colour scheme of Stanbol in the futurew
09:25:16 [sschaffert]: even IntelliJ has it now, so there is a trend :)
09:25:37 [sschaffert]: but not for now
09:25:45 [wikier]: ok
09:25:52 [sschaffert]: at the moment, priority should be easy to use interface
09:25:53 [wikier]: +1
09:25:53 [tkurz]: so. the colors can be changed within an hour
09:25:54 [sschaffert]: supporting the admin user
09:26:07 [sschaffert]: and
09:26:07 [wikier]: that means, next topic
09:26:07 [sschaffert]: supporting the developer
09:26:15 [sschaffert]: yes


# 5. user management #
09:26:46 [wikier]: not sure if I agree with tkurz about merging user management into core
09:27:07 [wikier]: [ok]


# 6. branding #


# 7. branding #
09:27:24 [sschaffert]: ok
09:27:34 [sschaffert]: saw your mail and forwarded it to Daniela
09:27:35 [wikier]: as far as I checked, we can feel free to use the logo
09:27:49 [sschaffert]: I will sit with her on Monday to discuss the different versions of the logo
09:28:02 [wikier]: ok
09:28:17 [wikier]: SVG and XCF/PSD would be nice
09:28:17 [jfrank]: will it be allowed to use the logo flipped?
09:28:19 [sschaffert]: maybe we can until then collect concrete requirements for sizes, colours and formats
09:28:33 [sschaffert]: whatever you want and Daniela agrees on :)
09:28:47 [wikier]: :-)
09:29:09 [wikier]: a monochrome version would be also nice
09:29:09 [sschaffert]: but why would anyone want to use it flipped? the text is hard to read except for nerds ;-)
09:29:24 [wikier]: xD
09:29:32 [sschaffert]: ok, no need to discuss it now, maybe collect it at the Jira issue
09:29:47 [sschaffert]: now I need to leave ... :-(
09:29:54 [sschaffert]: so cu :)
09:29:55 [wikier]: ok
09:30:02 [wikier]: cu sschaffert
09:30:24 [wikier]: I'll call for requirements in dev@
09:30:35 [wikier]: #action call for logo requirements
09:30:41 [tkurz]: okay
09:30:47 [wikier]: ok, back to user


# 8. user management #
09:31:10 [wikier]: as I said, not sure if I agree with tkurz about merging user management into core
09:31:19 [tkurz]: I want to integrate the access management filter into the core
09:31:26 [tkurz]: not the whole user management
09:31:40 [jfrank]: so the "security" part
09:31:47 [jfrank]: not the "user" part
09:31:54 [tkurz]: yes
09:32:09 [wikier]: what we should have in core is a user/security component
09:32:24 [wikier]: which could allow change the auth mechanism
09:32:39 [wikier]: form instance a web session
09:32:47 [tkurz]: yes. and the mechanism should be extedable by modules
09:32:47 [wikier]: but potentially others
09:32:48 [wikier]: right
09:32:49 [jfrank]: that's currently in "security"
09:32:54 [wikier]: ah, ok
09:33:02 [jfrank]: extensions are possible
09:33:12 [jfrank]: currently: local db and ldap
09:33:34 [wikier]: why not keep it there?
09:34:47 [tkurz]: mhh. the idea was that it is absolutely necessary in any use case
09:35:03 [tkurz]: but we can also keep it as it is
09:35:47 [tkurz]: my impression was, that we had many problems with that in the past
09:35:47 [wikier]: I don't have the details for voting this
09:35:54 [wikier]: you guys decide
09:36:04 [tkurz]: so a simplification might help
09:36:25 [westei]: How is security implemented?
09:36:41 [westei]: RESTful services or on component level?
09:36:47 [jfrank]: basically: regex on the request url
09:36:54 [jfrank]: REST only
09:37:09 [tkurz]: yes. and there is a very strange configuration
09:37:42 [wikier]: simplification would be fine, yes
09:38:02 [tkurz]: the problem was, that it does not always work as expected
09:38:09 [wikier]: maintenance is always a priority
09:38:11 [wikier]: tkurz: for instance?
09:38:24 [wikier]: just to get the details
09:38:40 [westei]: The other possibility would be to add Java Permissions on Component level (e.g. Allow to query a Graph)
09:38:47 [tkurz]: the problem is, that the mechanism is not transparent
09:38:54 [jfrank]: imho: protecting the REST interface is core business.
09:39:17 [jfrank]: and that's what we have currently
09:40:02 [westei]: But REST could be sometimes hard, as the same datasource could be mapped to different URIs
09:40:02 [jfrank]: @westei: true, but thats for the future
09:40:24 [tkurz]: Maybe we can keep it as it is but with more information, why access is denied
09:40:39 [tkurz]: otherwise it is not configurable without debigging mode ;)
09:41:24 [tkurz]: maybe we can solve the problem with a better UI
09:41:25 [wikier]: ok, I would suggest
09:41:32 [wikier]: keep it as it is
09:41:41 [wikier]: identify the issue that tkurz commented
09:41:54 [wikier]: and find proper solutions for next releases
09:42:17 [tkurz]: okay. I think about it until the next meeting
09:42:17 [wikier]: of couse, whatever that could be fix it now, being sure no lateral effects, fo rit for 2.6
09:42:18 [jfrank]: don't think that will work...
09:42:48 [wikier]: I'd like to have the actual issues described
09:42:59 [wikier]: maybe we should start a new implementation for scratch
09:43:07 [wikier]: I don't know...
09:43:14 [wikier]: s/for/from
09:44:08 [jfrank]: should we elaborate on that now or in a separate round?
09:44:37 [wikier]: +1
09:44:40 [tkurz]: okay. I will test it today and maybe will find a simple solution for now
09:45:14 [wikier]: ok


# 9. search #
09:45:44 [wikier]: jfrank: go ahead
09:46:07 [jfrank]: search is back on.
09:46:45 [jfrank]: currently i'm working on the issue with deleted cores that are re-appearing after restart
09:47:08 [jfrank]: seems line an error/misunderstanding in the configuration
09:47:16 [jfrank]: (ConfigurationService)
09:47:37 [wikier]: cool
09:47:46 [wikier]: we have that issue in all scenarios
09:48:24 [jfrank]: the problem is the CompositeConfiguration we are using, together with the List of available/enabled cores.
09:48:44 [wikier]: jfrank: could be related with lmf issue #122 ?
09:48:53 [wikier]: https://code.google.com/p/lmf/issues/detail?id=122
09:49:15 [wikier]: I think westei resolved it in a different way in Stanbol
09:49:37 [wikier]: (sorry, not a solr-expert)
09:49:52 [jfrank]: indirectly.
09:50:07 [jfrank]: more details now or f2f?
09:50:15 [wikier]: f2f
09:50:16 [wikier]: good


# 10. aob #
09:50:30 [wikier]: aob?
09:51:00 [tkurz]: yes I am
09:51:15 [tkurz]: bit nob ;)
09:51:37 [wikier]: what?
09:51:59 [tkurz]: no other business
09:52:14 [wikier]: yes, but what?
09:53:07 [wikier]: go ahead, tkurz
09:53:37 [wikier]: feel free to use #topic ;-)
09:53:59 [tkurz]: I said that I do NOT have aob ;)
09:54:07 [wikier]: ah, ok
09:54:14 [wikier]: ok, I have one
09:54:30 [wikier]: please, take a look to lmf issues
09:54:30 [wikier]: #link https://code.google.com/p/lmf/issues/list
09:54:45 [wikier]: to fix whatever could be fixed/closed for 2.6
09:55:07 [wikier]: that's it for me