Welcome to Elgg's documentation

This is the place to find documentation on all aspects of Elgg. If you would like to contribute your own documentation please do; we want this to be a real community effort!

From Elgg Documentation

(16:05:29) #elggdev: modus (+nt ) door irc.curverider.co.uk
(19:02:08) diego [~diego@200.71.48.65] is de ruimte binnengekomen.
(21:02:54) misja: hi diego
(21:17:04) diego: hi misja
(21:17:13) misja: hi
(21:19:33) diego: How much time left for the meeting?
(21:20:10) misja: 10 mins
(21:20:34) diego: ok
(21:29:21) ewout [~ewout@c934148d.virtua.com.br] is de ruimte binnengekomen.
(21:30:49) misja: hi ewout
(21:30:54) ewout: hi
(21:36:11) diego: Hi Ewout
(21:49:46) misja: guys, I'll be right with you in a minute
(21:53:52) diego: ok
(21:57:34) misja: ok here now
(21:58:52) misja: all present?
(21:59:18) ewout: well, let's start
(21:59:27) misja: ok
(21:59:47) misja: shall we pick Diego's summary as a start?
(22:00:20) misja: 1. New universal plugin install and uninstall API (For me this means a
(22:00:20) misja: more clever control panel plus introduce the changes that we already
(22:00:20) misja: talk about the plugin.info file and related stuff) 
(22:00:37) diego: :D
(22:00:52) diego: Yeap
(22:01:27) misja: wait, before we start running down the list, let's see if we can prioritize,
(22:01:33) misja: and detet dependencies
(22:01:36) misja: detect
(22:01:47) diego: ok 
(22:03:29) misja: much is related to plugin and generic API development, I think
(22:03:42) diego: yeap
(22:03:48) diego: And documentation :D
(22:04:20) misja: yes, documentation and API development should go hand in hand
(22:04:54) ewout: so 1.0 will get a new API?
(22:05:05) diego: I'm not sure
(22:05:21) misja: no, we'll have to see about that
(22:05:37) ewout: what are our thoughts on http://elgg.org/mod/mediawiki/wiki/index.php/Proposed_API and its relation to the API we have now?
(22:06:10) diego: Personally I like the general idea of make some API improvements but I don't like that approach.
(22:06:20) misja: we'll need to take another look at that
(22:06:27) ewout: ok, so if no new API in 1.0, what about the run() mechanism?
(22:07:05) misja: ideally I'd like to see the large include process go
(22:07:18) diego: I agree
(22:07:38) misja: so that's where api development kicks in
(22:08:02) misja: a separate templating system is part of that as well
(22:08:19) diego: I think that we must to start by there
(22:08:31) misja: ideally even a pluggable templating mechanism
(22:08:48) diego: yeap
(22:09:13) misja: so I think that would be a good place to bootstrap development
(22:09:19) diego: We have some points here with the Rolando's work
(22:09:43) diego: the next step, I think, is externalize all the HTML code
(22:09:44) misja: Rolando said he would be joining us in a minute, hope he can make it
(22:09:52) misja: would love to hear his thoughts
(22:09:55) diego: and then figure out how to make it better
(22:10:08) diego: ok
(22:10:08) misja: yes, exactly
(22:10:54) misja: my idea is that will model an API which in turn will impose restrictions on plugins
(22:11:26) misja: in the way they get constructed, and how they can access the system's capabilities in a uniform way
(22:11:34) diego: Can we think In something like a template team? I mean a group of us that would be responsible of do that job... think about it, make proposals
(22:11:36) diego: ...
(22:12:08) misja: yes, we'll definitely need some focus
(22:12:35) diego: An another one for other kind of features... like the plugin manager
(22:12:39) diego: What do you think?
(22:12:59) misja: I think that would be a good idea
(22:13:02) ewout: maybe we can include in the template stuff a uniform way to include css and javascript files
(22:13:19) misja: yes, that includes js and css too
(22:13:29) ewout: we really need a js library policy
(22:13:35) rho [~never@host-65-173-60-237.acelerate.net] is de ruimte binnengekomen.
(22:13:42) rho: hello world
(22:13:42) ewout: and a uniform, aproved way to include js and css
(22:14:01) diego: hello Rolando
(22:14:19) misja: hi rho
(22:14:33) diego: I had that task for the last release... :( I didn't have time to code it
(22:14:44) misja: rho, I'll send you a log
(22:16:24) misja: diego, no worries, now is the opportunity to do it in combination with templating
(22:16:48) diego: :)
(22:16:54) misja: rho, should be in your inbox
(22:17:50) rho: ok
(22:18:02) misja: btw, I was speaking to Pasi Havia before this meeting,
(22:18:25) misja: he and his company is very interested in contributing to a templating solution
(22:18:49) diego: :O
(22:18:52) diego: Interesting
(22:18:55) misja: (encore on elgg.org)
(22:19:24) ewout: what would that mean, a templating solution?
(22:19:40) ewout: a certain templating language?
(22:19:45) ewout: code to go with it?
(22:19:57) misja: to code what is needed to have templates separate from the rest of the code
(22:20:06) misja: and to use e.g. smarty
(22:20:54) misja: but that is what needs to get discussed
(22:21:00) diego: Has he some code already?
(22:21:05) misja: no
(22:21:12) misja: but is wiling to code
(22:21:14) diego: (Personally y like the Smarty idea :P)
(22:21:26) misja: I know :)
(22:22:03) misja: rho, what are your thougts?
(22:22:40) rho: i like the idea of a pluggable template engine
(22:22:53) diego: Rolando/Ewout/Misja. I said before that I think that we can do something like features teams: Template team, plugin manager team... for organize our work. What do you think about it?
(22:23:06) rho: smarty needs to learn new language
(22:23:22) diego: Smarty is not to different that HTML
(22:23:59) diego: ... however I think that would be the last step in the template engine improvement tasks 
(22:24:28) ewout: feature teams: well, there are only 4 of us
(22:24:59) diego: Before of thinking on Smarty or another thing. I suggest to try to externalize all the current HTML.
(22:25:01) diego: yeap
(22:25:27) diego: but we can work by couples
(22:25:55) ewout: to be clear: we are not now talking about user templates, right? we are talking about how elgg generates html
(22:25:56) misja: ewout, 5 actually, but true, that's why I am keen on getting other people in
(22:26:16) misja: yes, exactly
(22:26:32) ewout: the template language for users is a complety different issue
(22:26:46) misja: yes it is
(22:27:04) diego: So?
(22:27:23) ewout: just checking my understanding :)
(22:27:56) diego: ;)
(22:28:10) misja: having teams would be good, but we'll need to define them
(22:28:19) misja: templates is one
(22:28:30) rho: plugins engine
(22:28:32) diego: Admin panel?
(22:28:45) diego: Plugins manager?
(22:29:27) ewout: API development
(22:29:28) misja: I'd say plugins, which will include management screens/logic
(22:29:51) misja: thing is, all teams will be doing APIś
(22:30:22) diego: Yeap
(22:30:31) misja: so preferably not to many teams
(22:30:41) ewout: ok, so how about a "User Interface" group
(22:30:52) misja: probably template and plugin will suffice, I think?
(22:31:00) rho: core
(22:31:04) misja: ewout, good one
(22:31:23) ewout: people have complained about the UI since I became involved, but it needs a concerted effort
(22:31:42) misja: rho, would Jose be interested in participating in this area?
(22:31:46) diego: Sumarizing:
(22:31:47) diego: template engine
(22:31:47) diego: plugin manager
(22:31:47) diego: user interface/usability 
(22:31:47) diego: core
(22:31:49) diego: ?
(22:31:57) rho: misja, i'll ask him :)
(22:32:35) misja: that will be the list, although I'm sure about core
(22:33:31) misja: again, templates and plugin affect core directly
(22:33:31) diego: What would be the team members? Some theme preferences?
(22:34:00) diego: Rolando what exactly do you mean with core? 
(22:34:25) rho: core, about everything inside lib/*
(22:34:35) rho: lib/template should be moved into mod/template plugin i think
(22:34:41) rho: also lib/userlib.php into users plugin
(22:36:08) misja: shouldn't we redefine what should be core functionality?
(22:36:25) diego: I agree
(22:36:29) misja: as in, what does elgg actually provide?
(22:36:39) misja: what is elgg?
(22:36:53) rho: yes
(22:37:05) rho: i think elgg core must have only bootstrap and plugins engine
(22:37:44) diego: and some "core" modules
(22:38:16) misja: e.g. the user, shouldn't there be a central concept of a user?
(22:38:34) ewout: an accessrules to objects
(22:38:47) misja: or just a use API as an interface a module could provide?
(22:38:59) misja: *user API*
(22:39:19) diego: Elgg = bootstrap, plugins engine, users (API), access rules
(22:39:34) ewout: communities
(22:40:10) misja: communities I see more as a module
(22:40:34) ewout: how does the file module know that it can belong to a community?
(22:40:34) misja: being a way to organise the central concept of a user?
(22:41:14) misja: the file module should ideally know nothing about a community
(22:41:44) diego: even a user
(22:41:53) misja: true
(22:42:04) diego: a file is owned by someone
(22:42:25) ewout: I don't know, right now these things are pretty close coupled
(22:42:38) ewout: what do we gain by decoupling them?
(22:43:01) ewout: sure, it is cleaner, but we need to build on what we have
(22:43:04) misja: flexible and interchangeable components
(22:43:20) diego: Yeap, but I think that again we are talking about a lot of things at the same time
(22:43:27) ewout: I want to be able to upgrade
(22:43:28) misja: true again
(22:43:55) ewout: "a working complex system is the result of a working simpler system"
(22:44:11) ewout: well, you know all arguments off course
(22:45:08) misja: but still, I think we really need to define what we need
(22:45:19) misja: ie. what should be core
(22:47:15) ewout: I like the "user centered" concept, it is in line with recent web development: user centered this, user centered that
(22:47:42) ewout: but I don't know if it translates directly to the arquitectural level
(22:47:45) rho: i like the idea of really pluggable system, elgg must run even is there is any module.. of course it should do nothing
(22:48:03) diego: Elgg = bootstrap + plugins engine + users (API) + access rules + event_handling ?
(22:48:59) rho: event handling isn't related to plugins?
(22:49:26) misja: plus maybe concepts of an object and containers as high level interfaces
(22:50:17) misja: a generic event handling mechanism should be core, I think?
(22:50:38) misja: as a traffic controller
(22:50:56) rho: elgg objects has owner, type and access level, right?
(22:51:10) diego: yeap
(22:51:14) misja: yes
(22:51:33) misja: access level is something that should be stripped out of the object
(22:51:54) rho: and elggobjects always map into db table?
(22:52:00) misja: an object doen't need to know
(22:52:17) diego: yeap
(22:53:56) rho: well, when will we start on 2.0? :)
(22:54:10) rho: maybe we must define what must go on1.0 and what in 2.0
(22:54:14) misja: haha :)
(22:54:28) misja: yes, we will need to define that
(22:55:02) rho: sometimes it's better to start -almost- from scratch that fixing current code
(22:55:19) misja: exactly, for that matter 2.0 could be a completely different branch
(22:55:43) rho: elgg code are too explicit
(22:55:50) rho: lot of repeated code
(22:56:00) ewout: what about database compatibility? would you give that up?
(22:56:01) diego: yeap
(22:56:12) diego: That is a really big issue
(22:56:25) misja: ewout, that's something I'd like to tackle
(22:56:54) misja: with envy I look at some of the db abstraction libraries which handle them all
(22:57:23) misja: and not worrying about specific sql dialects
(22:57:30) rho: what about performance issues?
(22:57:35) ewout: not respecting plugin backward compatibilty is one thing, but not being able to migrate existing installations is a very big step
(22:58:23) rho: for example loading a css needs to load all elgg framework
(22:58:43) misja: which is why 2.0 shoudl be a separate track, with plenty of time to prepare migration paths
(22:59:06) diego: yeap
(22:59:15) rho: what about js/ajax library?
(22:59:27) misja: pluggable, ideally
(23:01:06) rho: for 1.0, migrate some legacy run() code, right?
(23:01:16) rho: like permissions_check() and run('permissions:check')
(23:01:33) rho: using $page_owner global or page_owner()
(23:01:54) misja: I think so, certainly if we get a templating system in
(23:02:04) rho: about run(), maybe we can keep backward compatibility
(23:02:14) rho: using run('callback_function')
(23:02:14) misja: we should start getting rid of the globals asap, if you ask me
(23:02:25) rho: that will be called, and if it's a file will be included
(23:02:34) diego: I'm not too sure about backward compatibility 
(23:02:42) ewout: rho, permission_check() only takes the owner of an object as an argument, would you consider adding the $blog of the object also?
(23:03:34) ewout: or passing not only the owner, but the whole object, like in the event handler
(23:03:53) diego: That could be good aproach
(23:04:44) ewout: I meant "the community" in which the object belongs
(23:05:02) ewout: not the $blog 
(23:07:24) rho: checking weblog and owner attribute?
(23:07:34) ewout: yes
(23:08:44) rho: ok, we can pass the object as ewout says
(23:09:28) rho: other issue are current plugins
(23:09:46) rho: some doesn't work out of the box
(23:10:59) rho: btw,  i checked folio plugin and it's php5 code
(23:12:10) misja: ah yes, that's a fine topic
(23:12:39) misja: should we still target php4?
(23:13:04) rho: i would say php4/5 compat, like cakephp framework
(23:13:08) ewout: I dont't have any opinion on the matter: what you decide is fine with me
(23:14:04) diego: Sumarizing...
(23:14:09) diego: What we do now?
(23:14:24) diego: We started talking about teams and now I'm lost :-/
(23:16:30) ewout: Ok, here is what I would like to do in the next month: 1. bug triage and solving 2. making UI proposals 3. work on newuser, export and maybe atompub plugins
(23:17:12) misja: first priority is to get 1.0 in shape
(23:17:32) misja: which inludes what you mention, ewout
(23:17:51) rho: current plugins support it's priority?
(23:18:12) rho: i meant the plugins in plugins repository
(23:18:23) rho: i could work on it
(23:18:49) misja: which ones?
(23:19:00) misja: most are already wuite old
(23:19:02) misja: quite
(23:19:12) rho: but people are trying to using it
(23:19:40) misja: I know, but I also think we'll need to draw a line
(23:20:07) misja: before you know it we'll be supporting all contributed plugins
(23:20:29) diego: I agree
(23:20:33) misja: there should also be some natural selection in this
(23:20:42) diego: I already started some work with my own plugins
(23:20:48) rho: *stream plugins
(23:20:55) misja: if a plugin is considered good, people should step in to maintain it
(23:21:02) diego: is setting up each plugin like a repository itself
(23:21:09) diego: trunk/ branches/releases
(23:21:39) diego: Maybe that would help people to know what is supported/compatible with the current version and what not
(23:21:45) rho: well, as young opensource community isn't too much contributors
(23:21:45) diego: What do you think?
(23:22:00) misja: rho, I know
(23:22:12) misja: but there is still only 5 of us
(23:22:48) misja: keeping a supported/compatible list is good
(23:23:34) misja: and some minimal backwards compatibility support also, but be careful
(23:23:36) diego: I can help organizing the plugins repository with the structure that I suggested}
(23:23:54) misja: sure, that would help
(23:23:59) rho: i think we all started with with elgg because we see as good tool to connect people, and we like opensource
(23:24:10) diego: And in parallel help with the compatible list in the page that we already have
(23:24:38) misja: rho, I know, but we need to be realistic as well
(23:24:45) rho: programmer contributors likes nice code and documented
(23:24:57) misja: true
(23:25:46) rho: i like the approach to make elgg more friendly to final users
(23:25:59) misja: but have a look at what you can/would like to support
(23:26:05) misja: as a start
(23:26:22) misja: I like the idea of forming of teams
(23:26:40) misja: shall we continue with that?
(23:26:50) diego: ehhh! yeap
(23:26:53) rho: i agree
(23:27:02) diego: I will like with the plugin manager stuff
(23:27:25) ewout: diego: what do you mean: every plugin directory will have trunk/releases/branches subdirectories? Don't you think that is too heavy-weight?
(23:27:26) misja: we had templating, plugins, core and ui, right?
(23:27:59) misja: plus for the brave a 2.0 team ;)
(23:28:10) ewout: maybe try to incorporate the plugin info file somehow, so that people know for which version of elgg the plugin was last updated
(23:28:34) misja: ah ewout, yes, of course
(23:28:53) diego: (Something like
(23:28:53) diego: plugins/messages
(23:28:53) diego: |-- releases
(23:28:53) diego: |   |-- 0.2.2.1-0.8
(23:28:53) diego: |   |   |-- languages
(23:28:55) diego: |   |   |   |-- es_CO
(23:28:55) diego: |   |   |   |   `-- LC_MESSAGES
(23:28:57) diego: |   |   |   |-- nl
(23:28:57) diego: |   |   |   |   `-- LC_MESSAGES
(23:28:59) diego: |   |   |   `-- pt_BR
(23:28:59) diego: |   |   |       `-- LC_MESSAGES
(23:29:01) diego: |   |   |-- lib
(23:29:01) diego: |   |   `-- templates
(23:29:03) diego: |   |-- 0.2.3-0.8
(23:29:03) diego: |   |   |-- languages
(23:29:05) diego: |   |   |   |-- es_CO
(23:29:05) diego: |   |   |   |   `-- LC_MESSAGES
(23:29:06) diego: |   |   |   |-- nl
(23:29:06) diego: |   |   |   |   `-- LC_MESSAGES
(23:29:09) diego: |   |   |   `-- pt_BR
(23:29:09) diego: |   |   |       `-- LC_MESSAGES
(23:29:11) diego: |   |   |-- lib
(23:29:11) diego: |   |   `-- templates
(23:29:13) diego: |   `-- 0.2.3-0.9
(23:29:13) diego: |       |-- languages
(23:29:15) diego: |       |   |-- es
(23:29:15) diego: |       |   |   `-- LC_MESSAGES
(23:29:17) diego: |       |   |-- es_CO
(23:29:17) diego: |       |   |   `-- LC_MESSAGES
(23:29:19) diego: |       |   |-- fi
(23:29:19) diego: |       |   |   `-- LC_MESSAGES
(23:29:21) diego: |       |   |-- nl
(23:29:21) diego: |       |   |   `-- LC_MESSAGES
(23:29:22) diego: |       |   `-- pt_BR
(23:29:22) diego: |       |       `-- LC_MESSAGES
(23:29:25) diego: |       |-- lib
(23:29:25) diego: |       `-- templates
(23:29:27) diego: `-- trunk
(23:29:27) diego:     |-- languages
(23:29:29) diego:     |   |-- es
(23:29:29) diego:     |   |   `-- LC_MESSAGES
(23:29:31) diego:     |   |-- es_CO
(23:29:31) diego:     |   |   `-- LC_MESSAGES
(23:29:33) diego:     |   |-- fi
(23:29:33) diego:     |   |   `-- LC_MESSAGES
(23:29:35) diego:     |   |-- it
(23:29:35) diego:     |   |   `-- LC_MESSAGES
(23:29:37) diego:     |   |-- nl
(23:29:37) diego:     |   |   `-- LC_MESSAGES
(23:29:39) diego:     |   `-- pt_BR
(23:29:39) diego:     |       `-- LC_MESSAGES
(23:29:41) diego:     |-- lib
(23:29:41) diego:     `-- templates
(23:29:43) diego: )
(23:29:43) diego: Sorry by the message spam :D
(23:29:45) diego: the plugin.info file is included in the plugin manager stuff I think
(23:30:17) misja: the release/control file could link back to an svn stucture - full circle
(23:30:35) ewout: also: let's link http://elgg.org/mod/mediawiki/wiki/index.php/Installing_plugins from the elgg.org/rac_plugins homepage
(23:31:02) misja: I'll do it rightaway
(23:31:08) ewout: oops, sorry, it is there already,
(23:31:31) misja: ah yes :)
(23:31:35) ewout: forget it :)
(23:32:01) diego: yeap
(23:32:18) misja: but still, the teams for 1.0
(23:32:40) misja: would everybody agree with the 4 I mentioned
(23:33:14) diego: yeap
(23:33:19) ewout: yeap
(23:33:29) rho: how teams will work?
(23:34:03) diego: My idea is that the team defines their own schedule about their topic
(23:34:31) rho: will have team members?
(23:34:36) diego: work on it and share with everybody their advances in this meetings
(23:34:56) misja: yes, they'll have team members
(23:35:26) rho: my proposal is to have one or two team leaders, that defines tasks and improvements on trac, then any contributor developer can work on it
(23:35:37) rho: that because we are few
(23:35:38) misja: would probably also be a good structure for occasional contributors, like Pasi
(23:36:44) rho: in my foss experience, when isn't more people, teams with formal structure doesn't work
(23:37:23) misja: that's true, but it will need a team lead, I think
(23:37:31) rho: surely
(23:38:26) misja: ok, time to name your preferred team(s) :)
(23:38:32) ewout: UI
(23:38:56) diego: plugins
(23:39:47) misja: templates, but not alone :)
(23:40:16) rho: i don't have preferred team  :(
(23:40:33) misja: not core?
(23:40:54) rho: core will affect all, right?
(23:41:00) diego: I can help on templates with the js/css think that I promise for the last release
(23:41:02) diego: :-|
(23:42:52) misja: ok
(23:42:59) ewout: and what will the deliverables be?
(23:43:02) misja: rho, true core affects all
(23:43:31) diego: Each team define it and let know to the others?
(23:43:59) rho: only-one teams?
(23:44:30) rho: i'll suggest to put all in trac, and we can discuss
(23:44:39) ewout: the wiki, you mean?
(23:44:53) ewout: or tickets?
(23:45:04) rho: i'll suggest add_messages() function, improve page_owner() to accept and argument that return and attribute of current page owner user
(23:45:06) ewout: we use trac only for tickets, right?
(23:45:07) misja: I think wiki for overview, trac for actions
(23:45:14) rho: like page_owner('user_type')
(23:45:28) rho: insetead of: global $page_owner; user_info('user_type', $page_owner);
(23:45:40) misja: yes, stuff like that
(23:45:59) misja: which is core
(23:45:59) diego: I agree. Wiki for overview and track for actions
(23:46:25) ewout: so will there be a new 2.0 milestone?
(23:47:02) misja: yes, think so, but a silent one for now
(23:47:12) ewout: (for things that would be very backward incompatible)
(23:47:20) misja: whch will probably also need a team
(23:47:58) misja: but this can come later
(23:48:16) rho: yes, there will be lot of discussions about 2.0
(23:48:24) diego: yeap
(23:48:29) diego: Guys I'm leaving
(23:48:34) misja: shall we set a deadline for team proposals?
(23:48:48) ewout: yes, good idea
(23:49:03) diego: Tuesday?
(23:49:30) misja: let's make it Wednesday, the day before we meet?
(23:49:36) ewout: ok
(23:49:57) rho: improves proposals?
(23:50:01) misja: yes
(23:50:30) diego: ok
(23:50:35) misja: btw rho, I'll team up with you for core stuff
(23:50:35) diego: See you guys
(23:50:40) misja: ok bye
(23:50:42) rho: yes
(23:50:52) diego: Misha' I will write you about the css/js stuff
(23:50:56) diego: byte
(23:50:57) misja: ok
(23:51:00) diego: And good coding
(23:51:01) diego: ;)
(23:51:05) diego is weggegaan.
(23:51:09) rho: btw, i'd made some core related functions in elggadmin/lib/engine.inc.php
(23:51:16) misja: right guys, getting late here too
(23:51:26) rho: maybe will need a review
(23:52:05) misja: post a patch?
(23:52:27) misja: diff I mean
(23:53:03) ewout:  I need to go too, good night to all
(23:53:10) misja: bye
(23:53:14) rho: bye ewout
(23:53:15) ewout is weggegaan.
(23:53:34) rho: better i will write proposals
(23:53:52) rho: but will need little help, what should have a good proposal?
(23:54:22) misja: a definition of a problem and a fix
(23:54:51) misja: but no worries, we'll team up
(23:55:13) misja: and prepare the proposals jointly
(23:56:03) misja: send around the modifications you mentioned, so everybody can have a look
(23:56:03) rho: ok
(23:56:25) misja: ok, will leave now
(23:56:36) rho: see you
(23:56:47) misja: we'll be in touch
(23:56:50) misja: bye