You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(19) |
Nov
(22) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(35) |
Feb
(5) |
Mar
(13) |
Apr
(9) |
May
(3) |
Jun
(16) |
Jul
|
Aug
(6) |
Sep
(15) |
Oct
(5) |
Nov
(3) |
Dec
(7) |
2003 |
Jan
(16) |
Feb
(10) |
Mar
(19) |
Apr
(13) |
May
(5) |
Jun
(20) |
Jul
(33) |
Aug
(9) |
Sep
(1) |
Oct
(12) |
Nov
(17) |
Dec
(2) |
2004 |
Jan
(3) |
Feb
(9) |
Mar
(7) |
Apr
(16) |
May
(6) |
Jun
(6) |
Jul
(18) |
Aug
(8) |
Sep
(27) |
Oct
(8) |
Nov
(14) |
Dec
(29) |
2005 |
Jan
(1) |
Feb
(11) |
Mar
(33) |
Apr
(2) |
May
(4) |
Jun
(21) |
Jul
(41) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2006 |
Jan
(8) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Antti <an...@di...> - 2006-10-07 00:54:02
|
(Note: This is a long mail. You might want to start with my request for comments/approval at the two last paragraphs to decide if you want to read the rest) In the last post to this mailing list, about half a year ago I tried to propose the notion of Action Environments. I still think they would be a nice thing and in this post I will try to touch on how it would fit in to the execution chain. So this post is mainly about the Controller class and how it would control the action execution. Currently Controller has been used mainly for handling how the content returned from the Action is sent to the requesting user. Controller however is in such a position in the request chain that it would be the correct place to do things also before the Action is executed. The obivous example for this is XMLRPC where the code which is to be executed is specified in the xml body of the content. Controller is the suitable place for parsing this XML and assigning the correct task to be executed along with the parameters. I however think that Controller should do even more. I think that Controller should be the part responsible for what parameters the Action object deals with and pretty much everything that the action sees of it's environment or changes in it's environment. In principle the Controller should control everything that the programmer might want to change if she was executing the Action manually. So some of the things now done in Actions execute method (like task resolving and additional assigning) should be done in the Controller before Actions execution. The easiest way I see this could be handled is that the Controller is responsible for setting up the (usually passthrough) Environment for the Action. I think that this would make it adequately possible to isolate the Action from the real Request, but I think that the issue of Action parameters should be looked at more closely. Currently we have quite a lot of ways to set parameters for an Action: Parameters fetched from Request (both POST parameters and GET parameters), parameters parsed using url_additional, parameters parsed from content (for example xmlrpc), parameters passed in to the Action's execute call and parameters received from action configuration. In addition to this there might be some defaults for the parameters and the programmer might want to change some of the values during execution. I think that it would be nice if there would be only one set of named parameters to work with (even if in the background there were many) and all these different ways to assign parameters would be assigned an order according to which they would automatically override the previously set values. I would suggest that the order (latter overrides former): 1. default parameters for tasks (action) 2. url_additional (controller) 3. GET parameters (controller) 4. POST parameters (controller) 5. content parameters (controller) 6. parameters from action configuration (action.ini) 7. parameters passed to execute (action) 8. parameters assigned during execution (action) How would these work in practice with Environments? 8. parameters assigned during execution: $self->param( param => $value ); 7. parameters passed to execute: As currently, moved to action parameters at the beginning of execute. 6. parameters from action configuration: As currently, first to properties and then to params at the beginning of execute. 5. content parameters Controller parses content and sets the parameters to environment: $environment->param( param => $value ); 4. POST parameters Parsed as currently but already existing GET values are overridden, not appended as a list. Stored in Request. Default Environment's param call queries Request for the parameter if no other value is set. 3. GET parameters Parsed as currently. Stored in Request. Default Environment's param call queries Request for the parameter if no other value is set. 2. url_additional Controller parses URL and sets the parameters to environment (after request is already attached to the environment): $environment->param_default( param => $value ); 1. default parameters for tasks In the beginning of the task, programmer would place: $self->param_default( param => value ); For this purpose we should extend ParamContainer to have param_exists and param_default functions which would tell if some param is touched and sets a param value only if it is not touched. With them Action and Environment param calls would (effectively) be something like: Action param { if ( $self->param_exists( $param ) { return $self->param( $param ); } else { return $self->env->param( $param ); } } Environment param { if ( $self->param_exists( $param ) { return $self->param( $param ); } else { return $self->request->param( $param ); } } I think that all this could be put into the system pretty much so that it would still retain backwards compatibility. All I can think of which would break it would be the POST & GET parameters ith the same name combining to an array (which I have myself always concidered a bug anyway ;)) In addition to this I would like to change the current Action behaviour in such a way that consecutive Actions executions with the same object would always have the same starting parameters regardless what happens in steps 7. and 8.. One way to do this would be to always start the action execute with an empty set of parameters before appending parameters in steps 6. and 7. This however might break some existing code that creates an action, sets some parameters and then launches it. I think a nice way to achieve this kind of pre-parameterizing could be to set the parameters to the Environment and if backwards compatibility is needed, Action could place parameters assigned to it staright to the environment if it is not currently inside the execute call. Full backwards compatibility can however not be guaranteed in case of old code reusing the same Action instance multiple times and expecting that changes to params done inside execute to be available in the next execute - but I don't think many (of those millions of OI2 developers ;)) use Actions like that. Now I would be grateful if somebody discussed/approved my ideas before I start implementing them. To summarize they are the following: * An Environment object for Actions through which Action can get all external data. * All parameters accessible through one param interface, using defined override sequence. * URL additional parameters appended to Environment params in Controller instead of Action params in Action execute. * Action params are cleared in the beginning of Action's execute. - Antti |
From: <an...@io...> - 2006-02-19 19:27:06
|
I read some of the old discussing actions. I'm not sure if I ever really laid out the problem space from my view, but I hope it can be somewhat clearly described this way: Actions are multi-purpose beings. We use them in the following forms: 1) Uses URL mapping. Called from the Controller. Does something which is defined by CTX->request. Let's call this a "Handler". 2) No url mapping. Called from an URL Handler. Does something which is defined by CTX->request and Action parameters. It produces a response. Let's call this a "Handler Call". 3) No url mapping. Called from an URL Handler. Does something which is defined purely by Action parameters. Let's call this a "Service Call". 4) No url mapping. Called from a Manage task. Does something which is defined purely by Action parameters. Let's call this a "Manage Call". URL Handler is the normal way of using an OI2 Action and Handler Call is a handy way to introduce page components (and maybe some functionality) from other packages. I think OI2 works for these two types of Actions. With Service and Manage Calls I have some small problems: The first problem comes with languages. By default the language is defined in CTX->request->language_handle, but I want to do my Manage and Service calls independent of the current request. So I should be able to set the language for my action. The second problem is Action "doing the right thing" in the case of a Service call. Action checks if CTX->request is present and does caching and message passing using the request if present. In Service calls I'd like to supply this information myself and it doesn't feel right to temporarily remove CTX->request each time I want to make a Service call. Then there is a nuissance with code reuse between Handlers and different Calls since Handlers and Handler Calls contain lots of references to CTX->request which can not be used with other Calls and which are not easy to "emulate". Since Handler Calls are probably the most common way to initially write functionality, you end up doing lots of refactoriung to your code when you need the same functionality as a Service Call or a Manage Call. Previously I had the suggestion that we should just add more accessors to the Action class so that we could emulate a request environment by assigning values to these accessors (which would otherwise fetch the from CTX->request) but as the Action class is becoming quite large, I suggest that we attach some kind of an Environment object to each Action instead. The suggested way to get information of your environment (request params, user, group, language etc) would be to use this environment object. By default this object could provide just hooks to CTX->request but would be completely customizable. What do you think about this? Should response or controller be handled through the environment also? If my Service Call shares code with a Handler which would do redirection, do we want this to affect the real response/require refactoring? Should Service calls be possible to be prohibited to alter main template params directly through controller? I'm sure that some of these issues could be circumvented using strict coding policies, like using Handlers and Handler Calls only as a wrappers which gather and pass all the relevant information to Service Calls, but this is not very intuitive and I'd rather make the Actions something which could be coded intuitively so that they can easily be reused for different types of calls. - Antti |
From: <an...@io...> - 2006-02-01 17:12:57
|
Antti V=E4h=E4kotam=E4ki wrote: > To me it seems that=20 > the session is always saved in the beginning of $response->send and thu= s=20 > the session is always saved even without the call in redirect-function. It seems that adapters are handling headers in redirect in a bit=20 different way. Both Standalone and CGI seem to output the headers=20 instantly, Apache2 calls function header_out (which I can find anywhere=20 - I think it should be just header) and Apache calls header-function to=20 store headers. Then each of them generates some headers in ->send phase. Maybe the fact that CGI and Standalone output headers instantly has=20 given the impression that save_session should be run over there, but i=20 think the ->send is executed from these adapters too, which would save=20 the session the second time. I will try to remove the session saving from redirects and modify all=20 adapters to just update header-accessor with the redirect information=20 (and not output it directly). I'll let you know if this seems to work. - Antti |
From: <an...@io...> - 2006-02-01 15:17:08
|
Chris Winters wrote: > Try that change and see what happens. I think I found the problem. I changed the $class->create as you instructed and because it caused the problems to be more visible, we figured out how to replicate the problem. The problem seems to happen in some cases where we do a redirect: Calling CTX->response->redirect calls $self->save_session, which in case of a tied session unties it. When Adapter calls $response->send, the $self->save_session is called again, but now the session is untied and for some reason lacks the _session_id key. Previously this just led to an error being reported (since no session was created by _create_session and it couldn't be sent to the user) but now this results in a new session being created which has no session id and thus the user is kicked out. We fixed this currently by removing the $self->save_session from the redirect-function, but I can't say for sure if it is somehow vital that the session is saved already at that point. You seem to have added the session saving to the redirect function in October 2004, commenting: "OIN-48: always save the session when doing a redirect" Do you happen to remember why you did that change? To me it seems that the session is always saved in the beginning of $response->send and thus the session is always saved even without the call in redirect-function. I also don't know why untie (or something else) removes the _session_id key, but because of that it seems that save_session should not be called twice or we end up in problems since we have already lost our session_id. So.. your insight on the matter would be more than welcome :) - Antti |
From: Chris W. <chr...@gm...> - 2006-01-22 16:32:01
|
On 1/21/06, Antti V=E4h=E4kotam=E4ki <ant...@he...> wrote= : >... > It seems that this call happens when CTX->request->session contains a > hashref which is not tied. I'm not sure how we can end up in this kind > of a situation and I don't know a way to replicate the bug we are > getting, so I don't know how (if at all) I could add the needed > parameters to the _create_session-call. A session is just a non-tied hashref if there's an error fetching it from the datastore, which typically happens in the case of an expired session. The OI user shouldn't care if the session is tied or untied, to her it's just a hashref. And the idea is that if any new interesting keys are added during the request we then create a brand new session, copy the data into it, and store it as normal. Looking at it now I'm pretty sure that call on line 141 of SessionManager.pm should be changed from: my $new_session =3D $class->_create_session; to my $new_session =3D $class->create; since that method will create a new session if not given an ID. Try that change and see what happens. Chris |
From:
<ant...@he...> - 2006-01-21 22:07:26
|
We have a problem that occasionally we get this kind of error messages in our log: 18:19:22 ERROR OI2.SESSION OpenInteract2::SessionManager (149) No value returned from _create_session; this shouldn't happen... The mentioned _create_session is called at row 141 of OpenInteract2::SessionManager: my $new_session = $class->_create_session; By looking at the implementations of _create_session in the subclasses of OpenInteract2::SessionManager, it seems to me that _create_session is no supposed to be called without parameters. Now I would fix this but I'm not quite sure how ;) It seems that this call happens when CTX->request->session contains a hashref which is not tied. I'm not sure how we can end up in this kind of a situation and I don't know a way to replicate the bug we are getting, so I don't know how (if at all) I could add the needed parameters to the _create_session-call. Would somebody happen to have an idea of what might cause an untied hashref session and what would that hashref contain when this happens? - Antti |
From: Chris W. <chr...@gm...> - 2006-01-15 21:57:18
|
On 12/22/05, ant...@he... <ant...@he...> wrote: > I noticed that most of our SPOPS configurations look pretty much the > same (or follow the same pattern). > > It would be nice to be able to set some default values or generation > rules for all of the SPOPS classes in one project - at least our spops > configuration entries could in most cases drop from the current: > ... > The easiest way to do this would be to modify > OI2::Setup::ReadSPOPSConfig but currently there is no way to extend or > replace that piece of code. This reminds me of the problems with > ActionResolvers, since the problem stems from the discovery of "all > applicable factories". > > To me it seems that using an automatic find mechanism to determine which > classes should be used for setup / action resolving is causing problems > and I propose that the find mechanism would be replaced with a list of > modules in a configuration file (probably server.ini). > > This way one could replace ReadSPOPSConfig with a custom one so that it > would still qualify for other tasks that depend on 'read spops config'. This is an interesting idea, and one of the benefits of abstracting the dependencies to names ('read spops config') instead of classes. I think we could probably do something like: a) keep the autodiscovery (this is very useful) b) allow you to specify in the server.ini that certain setup classes should NOT be used, even though they're discovered You could then create your own class to implement similar functionality, return 'read spops config' from get_name() and allow it to be discovered as normal. When we assemble the setup actions we'd first check the server config to see what we should remove and get rid of those. > Even if there would be a way to make this SPOPS default configuration > using some global configuration file and specialized syntax for > generation rules (which I'm sure there would), I think it is very > important that changes like these are made possible. Sure, I agree. We might as well make EVERYTHING configurable :-) Chris |
From: <an...@io...> - 2006-01-15 18:08:03
|
Chris Winters wrote: > True, but I'm not sure why a package would want to eliminate observers. I meant that you can't use global configuration to eliminate observer mappings issued in packages. (Like action-override.ini and spops-override.ini do for actions and objects) > I think using object/subroutine observers is a mistake: it just adds > more syntax for very little gain, since class-based observers should > be generic enough for everyone. I agree. > I don't think so. Adding the 'observer_map' section to the package > should be sufficient, and adding yet another configuration file should > be something we do only if we absolutely have to. It just feels odd that this kind of functionality is defined in package.ini (which doesn't end up even in the websites conf-directory), but i'll do the observer_map and leave it at that for now. > I can see the package-level observers being useful to implement > application functionality without the end user having to know about > it, but global observers being useful to apply common rules to many > different objects without those objects knowing it. This brings up the question - should we make a similiar easy way to attach observers to objects of some type? I think the only way to attach "triggers" to objects from other packages (or from the same package without modifying the object) is to use global spops-override.ini and manipulate ISA. For example if I would like to do something each time a user object (from package base_user, without using global overrides) is removed, I would now have to modify each location in the code where a remove is issued to notify observers and then map my observer to all the actions doing some user deleting. Would separate 'observe_action' and 'observe_object' be a good approach? - Antti |
From: Chris W. <chr...@gm...> - 2006-01-15 17:18:25
|
On 1/15/06, Antti V=E4h=E4kotam=E4ki <an...@io...> wrote: > You have even commented it this way so I thought you might have some > good reason: > > "Mapping an observer to an action is exclusively done in > C<$WEBSITE_DIR/conf/observer.ini>." I can't think of the reason; hopefully I just added that comment for clarit= y. > One reason I thought up when doing that change was that you can not > disable those mappings in any way from the global configuration - you > can just add more mappings. True, but I'm not sure why a package would want to eliminate observers. > Also I noticed that because package.ini requires the package-namespace > to be used, you can not define object- or subroutine-based observers - > only class observers (I don't need them, but still..). I think using object/subroutine observers is a mistake: it just adds more syntax for very little gain, since class-based observers should be generic enough for everyone. > Would it be better to let packages just define their own > conf/observer.ini files? (If the need arises, they can then be made > overridable by observer-override.ini) I don't think so. Adding the 'observer_map' section to the package should be sufficient, and adding yet another configuration file should be something we do only if we absolutely have to. > Should I do this instead / also? Sure, go right ahead! I have very few cycles to devote to this right now (perils of having an interesting day job). > PS. For what purpose would one need the global observer.ini if you can > define observers and mappings in packages? A very useful aspect of an observer is that it can be applied by the end user, and I think the end user is much more likely to read/modify global configuration files than package-level configuration files. I can see the package-level observers being useful to implement application functionality without the end user having to know about it, but global observers being useful to apply common rules to many different objects without those objects knowing it. Chris |
From: <an...@io...> - 2006-01-15 17:06:46
|
Chris Winters wrote: > I think it's just because I never thought of it :-) Patches (or > commits) would be great. (I assume you're initializing the map in > OI2::Observer->initialize()?) Just one note: I'd name it > 'observer_map' instead of 'map' in the package.ini just to eliminate > ambiguity. You have even commented it this way so I thought you might have some good reason: "Mapping an observer to an action is exclusively done in C<$WEBSITE_DIR/conf/observer.ini>." One reason I thought up when doing that change was that you can not disable those mappings in any way from the global configuration - you can just add more mappings. Also I noticed that because package.ini requires the package-namespace to be used, you can not define object- or subroutine-based observers - only class observers (I don't need them, but still..). Would it be better to let packages just define their own conf/observer.ini files? (If the need arises, they can then be made overridable by observer-override.ini) Should I do this instead / also? - Antti PS. For what purpose would one need the global observer.ini if you can define observers and mappings in packages? |
From: Chris W. <chr...@gm...> - 2006-01-15 16:49:19
|
On 1/15/06, Antti V=E4h=E4kotam=E4ki <an...@io...> wrote: > ... > And then noticed that observer _mappings_ defined in packages are not > applied at all. > > Is there some reason for this or would you accept a patch to apply also > mappings from packages' package.inis? I think it's just because I never thought of it :-) Patches (or commits) would be great. (I assume you're initializing the map in OI2::Observer->initialize()?) Just one note: I'd name it 'observer_map' instead of 'map' in the package.ini just to eliminate ambiguity. Chris |
From: <an...@io...> - 2006-01-15 14:48:38
|
Chris, I couldn't get my observers working when defined in package's package.ini like this: [package observer] myobs = OI2::... [package map] myobs = someaction And then noticed that observer _mappings_ defined in packages are not applied at all. Is there some reason for this or would you accept a patch to apply also mappings from packages' package.inis? - Antti |
From: <ant...@he...> - 2005-12-22 12:38:44
|
I noticed that most of our SPOPS configurations look pretty much the same (or follow the same pattern). It would be nice to be able to set some default values or generation rules for all of the SPOPS classes in one project - at least our spops configuration entries could in most cases drop from the current: [my_object] class = OpenInteract2::MyObject field_discover = yes id_field = my_object_id increment_field = yes is_secure = no no_insert = my_object_id no_update = my_object_id base_table = my_object to: [my_object] class = OpenInteract2::MyObject The easiest way to do this would be to modify OI2::Setup::ReadSPOPSConfig but currently there is no way to extend or replace that piece of code. This reminds me of the problems with ActionResolvers, since the problem stems from the discovery of "all applicable factories". To me it seems that using an automatic find mechanism to determine which classes should be used for setup / action resolving is causing problems and I propose that the find mechanism would be replaced with a list of modules in a configuration file (probably server.ini). This way one could replace ReadSPOPSConfig with a custom one so that it would still qualify for other tasks that depend on 'read spops config'. Even if there would be a way to make this SPOPS default configuration using some global configuration file and specialized syntax for generation rules (which I'm sure there would), I think it is very important that changes like these are made possible. - Antti |
From: Chris W. <chr...@gm...> - 2005-10-28 14:04:11
|
On 10/28/05, Torsten Foertsch <tor...@gm...> wrote: > Hi Chris, > > I have got OpenInteract2 now running with mp2. The following patch was ne= eded. I'll explain > parts of it here inline. It is attached as a complete patch again. > ... Thanks a ton! I was going to try and do this in the near future to get my website working under MP2, but now I'll just be a test for your patch :-) Chris |
From: Teemu A. <te...@di...> - 2005-08-05 15:47:18
|
> What do you guys think of adding .deb and .rpm build information to the OI2 > (and SPOPS) packages in CVS? > > AFAIK it would be enough with a .spec file for RPMs and a debian/ dir (with the > necessary makefiles) and perhaps adding a couple of tings to the MANIFEST.SKIP > file... > > Is that a sensible idea? :) Do it! And a script to build them on target platforms. -- Teemu Arina, CTO Ionstream Oy / Dicole Nelikkotie 2 B 67 02230 Espoo FINLAND Tel: +358-(0)50 - 555 7636 skype: infe00 Corporate website: http://www.dicole.com "Discover, collaborate, learn." |
From: Salve J N. <sal...@me...> - 2005-08-05 15:09:46
|
Hi! What do you guys think of adding .deb and .rpm build information to the OI2 (and SPOPS) packages in CVS? AFAIK it would be enough with a .spec file for RPMs and a debian/ dir (with the necessary makefiles) and perhaps adding a couple of tings to the MANIFEST.SKIP file... Is that a sensible idea? :) - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
From: Chris W. <ch...@cw...> - 2005-08-04 14:32:34
|
oops, put the wrong 'to' address in... ----- Forwarded message from Chris Winters <ch...@cw...> ----- From: Chris Winters <ch...@cw...> To: Salve J Nilsen <sal...@me...> Cc: oen...@li... Subject: Re: [Openinteract-commits] CVS: OpenInteract2/lib/OpenInteract2/Setup CreateTemporaryLibraryDirectory.pm,1.4,1.5 Date: Thu, 4 Aug 2005 10:46:33 -0400 Message-ID: <200...@ww...> * Salve J Nilsen (sal...@me...) [050804 08:46]: > Chris Winters wrote: > >Update of /cvsroot/openinteract/OpenInteract2/lib/OpenInteract2/Setup > >In directory > >sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31019/lib/OpenInteract2/Setup > > > >Modified Files: > > CreateTemporaryLibraryDirectory.pm > >Log Message: > >add 'devel_mode' to top-level server config; if set to 'yes' we recreate > >the temporary library directory every restart > > I loved this patch. Thanks! :-D I actually did this at YAPC::NA thanks to some comments from Perrin -- it was very easy and just took someone new(ish) to point out some useful functionality. Chris ----- End forwarded message ----- |
From: Salve J N. <sal...@me...> - 2005-08-04 12:30:50
|
Chris Winters wrote: > Update of /cvsroot/openinteract/OpenInteract2/lib/OpenInteract2/Setup > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31019/lib/OpenInteract2/Setup > > Modified Files: > CreateTemporaryLibraryDirectory.pm > Log Message: > add 'devel_mode' to top-level server config; if set to 'yes' we recreate the temporary library directory every restart I loved this patch. Thanks! :-D - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
From: Salve J N. <sal...@me...> - 2005-08-01 13:57:15
|
Jeff Howden wrote: > Salve, > >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >>I hope these "requirements" aren't too difficult. >> >>Are you up for it, Jeff? :-) >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > > Time is the only issue. How are things moving along? Do you need any help? :) - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
From: Salve J N. <sal...@me...> - 2005-08-01 13:10:31
|
[Sorry for the verbosity of my ranting :)] Antti Vähäkotamäki wrote: > Salve J Nilsen wrote: >> >> [snip] > > Also I think that it is very hard to make something easy to develop if there > are no guides on what is the preferred outcome. It's like coding with bad > specs - you hack up something and hope that it is suitable. This is not a > good way to encourage contributing to OI2 itself. I'm of course assuming the contributor has some common courtesy when it comes to submitting significant changes (but since assumption is the mother of all fsck-ups, we make sure CVS is there to save the day. ;-) Anyway, I'm trying to postulate that motivating people to do something is much more difficult than deciding what to do. To do the latter, one only has to have a look at JIRA to get started, or try to take notice of things that are difficult to do when creating an OI2 app (I'm sure you can think of more)... Since we're talking about an Open Source project, we can basically say bye-bye to extrinsic motivational tools like salaries or the threat of layoffs. This leaves us with the intrinsic ones, which basically have the drawback of being highly personal, e.g. the wish to write good code, scratch your itch, help a friend, pride, reputation or self-education. From the project's point of view, I'm sure we'd like to allow everyone to make use of their motivation as they seem appropriate, and AFAIK, the most sensible way to do this is to have an "including" demeanour towards those who want to contribute - giving them trust and responsibilities - and to reduce the number of hurdles one has to jump through in order for someone to actually make a contribution. (I'm sure there are more ways.) If we manage to arrive at this point (no hurdles, positive community, etc.) I think we're basically members of a do-ocracy - "Just do it, we trust you!". I think that's a good thing. :-) > [snip] > > I think this is the best way we can help OI2 to advance as a project since > the more people write their applications on OI2, the more we can identify > places where OI2 should be developed futrher to achieve our mission - and we > will probably even get help for doing it. > > I think that if OI2 has no clear mission, everybody will concentrate more on > building their own missions and OI2 will always remain just half made > everything. Sure. Do you have a suggestion for a mission statement? :) >> OI2 is an open source project, dammit. Why bother with the self- >> scrutinizing philosophical questions when we can change the world with >> code? We _have_ the freedom to do watever we want, and _that_ is why I'm >> sure you can mold OI2 into whatever you want it to be... :-) > > Open source project is just like any other project: to succeed it needs good > management. Lonesome coders hacking away as they see fit is not going to > end up being everything we all need. If you think you're a lonesome coder, then I'm sure you actually are. If you feel you need management, then I'm sure you actually need management. But if you take the time to count the members of this mailing list, you'll quickly see that you _aren't_ alone (even if we're a quiet bunch), and if you try to do something that's useful for OI2 all by yourself, I'm sure you'll see that we cab be quite positive to your contribution (if we find the time, we might even comment and critique it. :) > We need to discuss the directions where we are going so that we can benefit > on each others work. I can write a million hello worlds within an hour by > using OI2 and some code generation, but it is not going to change the world. Just tell us what you're doing.. ;-) >> Chris, is it feasible to give people access to improve the website? > > To suddenly change the mission statement the way one wants it instead of > discussing it with all the others first? ;) If you feel like being efficient, then sure. Just make sure it's an obvious improvement. (Otherwise we'll revert it and remove your write access ;-) >> What's more important? That new users and developers can get a site up and >> running easily, or that experienced developers have a "clean install" to >> work from? > > In my opinnion both are important and they are in no way conflicting goals. > Ofcourse it is very important to have example code or even an example system > you can build upon if it _happens_ to fit your needs. But building upon the > example code should IMO not be the expected usage. > > I think the expected usage should be that you pick a collection of the > example modules you need and build your application using those. My experience is that one shouldn't expect a specific kind of behaviour from users... Why not just "expect people to use stuff in new ways", and make sure the APIs are consistent and clean, everything is subclassable, neatly modularized and all significant events are logged? I think that would be a nice start, at least. :) >> Should OI2 _only_ be an application framework, or should it also be usable >> ("out-of-the-box") as a corporate intranet? Or a collaboration tool for a >> volunteer organization? Or a generic frontend for a database? Should we >> be allowed to choose? > > I think OI2 should be _only_ an application framework. Simply said. Then I'm sure you'll commit code and report issues so OI2 moves in that direction. :) >>> Although the lower level functionality is important, sometimes these >>> also do not serve the purposes. >> >> (A little off topic here: I think it would have been _much_ better if you >> improved OI2 instead of replacing parts of it. :) > > What do you mean by improving OI2? Anything that you have found lacking in OI2 and fixed in your app, could be made part of OI2 in the core (or as an easily accessible option). E.g. if you find that the security system is too slow (and determine the reason is the amount of database access), then you could create a drop-in replacement for base_security (or whatever is appropriate) so other people also can get the option to use your "base_security_fast" package. Or you could write the documentation (to be placed in the as-yet non-existent OI2 HOWTO) which describes how to configure OI2 to cache security lookups better or how to create applications that access the slow security features less often. I'm just making things up here, but I'm sure you understand what I'm trying to say: When working with an OSS framework, the framework's value grows faster when everybody involved tries to improve the framework for the general case before creating the "special case" solutions. > We have only 2 patches against the OI2 cvs tree, of which one is already > obsolete because of the changes in OI2 tree and the other is already > reported in JIRA and is being discussed - we can't just go and commit the > code before discussing with Chris even if we have commit access to CVS. Chris is busy. Should everything really have to stop because he has something else to do? (BTW, This looks like a classic single point of failure scenario... :-\ ) > Then we have our own version of many of the factory classes in OI2, but even > many of those changes are either discussed on the dev list or reported in > JIRA as change suggestions. Do they solve some general issues? Can the classes you've made be generalized enough to be included into OI2? Have you attached the code you've made to the JIRA issue, so others can have a look at it? :) > Then we have some packages which are used to test some approaches and which > in the end _might_ end up into OI2 as ideas, but are currently implemented > so that they are not near generally usable. On the other hand they might > provide to be immense crap. Publish them on your own webserver, and let other people decide. Set up a new category in JIRA, and create an issue there, so people can give structured feedback. Find other ways to tell us what you're up to. :) > Also there is lots of code which will never find it's way into OI2 because > it's application specific. I very much doubt that Chris would want our > bloated security framework into OI2 since the whole structure is heavily > dependent on our applications view on groups and users and we ignore SPOPS > securities for management reasons. Hm. So you're creating boated application specific code? Tsk, tsk. (BAD developer! Now go and read "Big Ball of Mud" and "Code Smell" ;-) > On top of our specific focus, we have limited resources and tight schedules, > like everybody in this business has. We just simply don't have the time to > plan and test our approaches as long as we find a way that might be > integratable with OI2. Usually the good ideas grow in time and they need a > lot of experimenting in different directions to evolve to a general state. > We can't just decide that we will make everything as general as possible to > be incorporated into OI2 core even if we wanted to. We do what we can given > the resources, but usually the output is far from general and reusable > Brick. When it evolves, maybe? Well, I hope you'll find the time to make your code general enough for OI2, some day... :-) > But the sad fact is that we can't dump the customers who pay our bread to go > on a crusade to build a better world - we are already making as many stabs > as we can towards that goal. So your customers aren't interesting in building a better world? (Just kidding. I'm sure you try as best you can. :) >> For example, find the parts of Dicole which are (almost) general enough >> for everybody to use, and find a way to move it out of Dicole and into OI2 >> instead. > > We can't just decide ourselves that OI2 needs this and that and completely > wreck the CVS without asking anyone. We have to discuss and agree about > things - like the things we are talking about in this mail thread. You could start by creating a separate branch in the OI2 CVS for your experiments... :) - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
From: Chris W. <ch...@cw...> - 2005-07-31 00:39:59
|
On Jul 18, 2005, at 4:36 PM, Antti V=E4h=E4kotam=E4ki wrote: > I think Teemu was trying to say that setting goals and guidelines =20 > is a very important part of making OI2 developer-friendly. I agree =20 > that is it mainly important for the end users who write their =20 > applications on OI2, but the fact is that we will probably never =20 > get people on board who are just OI2 developers - their motivation =20 > will always (at least in the beginning) be their own application =20 > which runs on OI2. It's just the way open source projects usually =20 > work. I agree with that -- most of us don't participate in the actual =20 development of core Perl, we just use it. > ... > The questions from the people who are interested in OI2 are more =20 > probably going to be: "How easy does using OI2 makes it for me to =20 > do A?" and "Has someone already done A on OI2 and could I benefit =20 > from it?" and thus these are also the questions we should be =20 > thinking when we develop OI2. > > A huge part of addressing the first question id to provide a clear, =20= > detailed mission statement and a bug repository + documentation =20 > stating which features are missing or buggy and need more work. > ... > I think that if OI2 has no clear mission, everybody will =20 > concentrate more on building their own missions and OI2 will always =20= > remain just half made everything. It's true, OI has never had a real mission statement. I suppose I'm =20 the natural person to write such a thing, but that it hasn't been =20 done yet is a good indication that it probably never will be if left =20 in my hands. Is someone interested in coordinating this? > ... > Open source project is just like any other project: to succeed it =20 > needs good management. Lonesome coders hacking away as they see fit =20= > is not going to end up being everything we all need. > > We need to discuss the directions where we are going so that we can =20= > benefit on each others work. I can write a million hello worlds =20 > within an hour by using OI2 and some code generation, but it is not > going to change the world. Also true. > ... > To suddenly change the mission statement the way one wants it =20 > instead of discussing it with all the others first? ;) Probably more to replace me as a bottleneck and change the statement =20 (and site) once interested folks have agreed to it. > ... > On top of our specific focus, we have limited resources and tight =20 > schedules, like everybody in this business has. We just simply =20 > don't have the time to plan and test our approaches as long as we =20 > find a way that might be integratable with OI2. Usually the good =20 > ideas grow in time and they need a lot of experimenting in =20 > different directions to evolve to a general state. We can't just =20 > decide that we will make everything as general as possible to be =20 > incorporated into OI2 core even if we wanted to. We do what we can =20 > given the resources, but usually the output is far from general and =20= > reusable Brick. When it evolves, maybe? But the sad fact is that we =20= > can't dump the customers who pay our bread to go on a crusade to =20 > build a better world - we are already making as many stabs as we =20 > can towards that goal. True for many people I think. It's a delicate balance making your =20 core products open source: if you don't work enough on the core =20 you'll lose the benefits of them being open source, but if you spend =20 too much time on it you won't be writing applications for people who =20 pay you money. As always, thanks for your ideas. Chris |
From: Chris W. <ch...@cw...> - 2005-07-31 00:00:35
|
Sorry I've been missing much of this -- I switched mailers for a few weeks (not by choice) and Thunderbird doesn't float new threads up to the top like Mail.app does. Just another dumb user error. On Jul 18, 2005, at 12:36 PM, Salve J Nilsen wrote: > ... > Basicly I agree with you, but I also think the question of "wether > or not OI2 > is a CMS (or has a clear end-user decipherable mission statement)" > isn't the > most important question at this stage. Today, I think we're much > better off if > we try to make OI2 as developer-friendly as possible. That sounds good. I think it would be great to reach out to users but you really need apps for that, and we don't have them right now. > To do this, it may help to point out that OI2 isn't a _product_, but a > _project_. Asking product questions (e.g. "Does it do A") can be > useful, but > not nearly as much as asking project questions (e.g. "Can someone > help me write > feature A" or "How can we make it easy for someone to write the A > feature"). It's a subtle difference, and users usually can't recognize it. (Not that it's a bad thing, just different.) > If we hace a quick look at the state of OI2 (today), it may look > something like > this - AFAICT: This is a really good summary! I'll try to chime in where it's interesting... > 1) OI2 is Big and Complicated > 2) Although the beta period for OI2 has lasted forever(tm), > there's still a > large amount of bugs (currently around 60 in JIRA). :-\ Yes. This is tied in with "Chris does everything and is swamped", unfortunately. > 3) OI2 has some good "infrastructure" features but few "application" > features. Developers like the former, users the latter. Who's > more > important? Right. Maybe people do build apps but are shy to publish? Or maybe since there's no real distribution mechanism the necessary infrastructure isn't there? (Maybe the 'publish to CPAN-distributable module' will help?) > 4) OI2 is pretty well documented (I'm guessing 75%), but lacks a > lot of > common things that make large amounts of information more > comprehensible > to the reader (e.g. ER diagrams, class diagrams, data flow > diagrams). > 5) The OI2 community is too small and quiet. :-( Again, I think this is the issue where one person (me) has been the main developer. Since I'm not contributing as much as I used to it becomes a problem. > 6) Contribution to the project is difficult - perhaps due to > social quirks > (shyness of speaking in public fora? our inability to follow > up requests > on this mailing list? the "Jante law"?), I haven't heard of this. Time to google...wow, that's really interesting. This is a good link: http://www.bbc.co.uk/dna/h2g2/A668694 > but also due to technical > complexity (finding where to add a feature requires a lot of > digging). True. It would probably be useful to have a FAQ-like guide for this. > 7) One _can_ say OI2 has a lacking webpage, unclear about mission > and > perspective. True. > 8) We have an underutilized wiki (is anyone actually reading or > using it?) True. > 9) The mailing list archives and bugtracker have little sense of > connection > between them, the website and the wiki. What can we do to make > all this > information less fragmented? Is there a way we could integrate > JIRA with > the main site? Or use a OI2-native wiki instead of TWiki? Good questions. > 10) We have only a vague sense of what kind of audience OI2 is > for. It seems > to be mainly for advanced web application developers, but we'd > like more > people to use it, right? Right. > 11) Chris has always been doing most of the significant > development, but like > the rest of us, he's swamped in distractions from from doing > the Important > Stuff - namely improving OI2. :) Right! > All these points lead to interesting project questions. Ask > yourself these > questions, find if some of them interest you, try to answer these, > and finally > try to implement the answer. (And should you come across something > that stops > you from implementing it, then fix that first) > > OI2 is an open source project, dammit. Why bother with the self- > scrutinizing > philosophical questions when we can change the world with code? We > _have_ the > freedom to do watever we want, and _that_ is why I'm sure you can > mold OI2 into > whatever you want it to be... :-) ! > Sure. Fix it if you have access, write a bugreport if you haven't. > > Chris, is it feasible to give people access to improve the website? Absolutely! If you're interested let me know. > What's more important? That new users and developers can get a site > up and > running easily, or that experienced developers have a "clean > install" to work from? > > Should OI2 _only_ be an application framework, or should it also be > usable > ("out-of-the-box") as a corporate intranet? Or a collaboration tool > for a > volunteer organization? Or a generic frontend for a database? > Should we be > allowed to choose? The basic applications (like news, lookups, the super-simple CMS) were mainly put there so you didn't install OI2 and say, "Okay, now what?" You'd have something to tinker with and break as well as examples to follow. But since it's easy to swap functions in and out, maybe it makes sense to have a stripped down distribution (*no* apps, just basic user/security stuff) and the version as it is today? It would be doable with Module::Build rules, I think... I really appreciate that you folks are interested enough in OI2 to get involved with big picture ideas like this. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: <an...@io...> - 2005-07-28 02:05:34
|
I once again started wondering what is the role of the action class.. Action implements many functionalities but I think many of them are not necessarily core action functionalities.. Questionable ones are imo content generation, message carrying, url creations, task validation+ url_additional setting and even caching or security. I know that you can turn the above functionality off or just ignore that it is there, but as Chris said, the Action class is quite huge already. If I recall correctly, OI1 had a different class for "handlers" and "actions".. I think handlers were more like special actions with the above functionality.. Why was this separation dropped? I think it would make the structure easier to understand if it would be made clear that "handler"-actions are only one way to use actions. As I have said before, I think that finding a valid task and setting url_additional would IMO be more like actionresolvers task than actions. Also message carrying might be wise to be moved elsewhere since it might be nice to be able to show messages also when redirecting away from an action, or showing messages that sub-actions (like box beneration) produce. Url creation is pretty useless if the action isn't a "handler" and content generation is only needed if the action is supposed to output processed data instead of perl structures. Caching is a good property in an action, but on many occasions it is not used since it is quite a hassle to invalidate caches. Sometimes even security is not needed for an action. I think it would be easier to grasp the concept and usage if there were several action classes instead of just one with a lot of configuration options. I think we might have at least OI2::Action OI2::Action::Cached OI2::Action::Secured OI2::Action::Generated OI2::Action::Handler (unifies the above and adds url handling) Actions execute could then check if the action ->can the extra functionality and thus they could be added just by using the wanted classes as base without bloating the actual Action code. OI::A::Generated could for example pass the return value of the task to a content generator automatically if $self->skip_generate is not specified. Any of you have other views on the subject? =) - Antti |
From: <an...@io...> - 2005-07-18 20:35:54
|
Teemu is on a vacation this week so I'll try to answer for him since I think this is quite an important topic. Salve J Nilsen wrote: > Basicly I agree with you, but I also think the question of "wether or > not OI2 is a CMS (or has a clear end-user decipherable mission statement)" isn't > the most important question at this stage. Today, I think we're much better > off if we try to make OI2 as developer-friendly as possible. I think Teemu was trying to say that setting goals and guidelines is a very important part of making OI2 developer-friendly. I agree that is it mainly important for the end users who write their applications on OI2, but the fact is that we will probably never get people on board who are just OI2 developers - their motivation will always (at least in the beginning) be their own application which runs on OI2. It's just the way open source projects usually work. Also I think that it is very hard to make something easy to develop if there are no guides on what is the preferred outcome. It's like coding with bad specs - you hack up something and hope that it is suitable. This is not a good way to encourage contributing to OI2 itself. > To do this, it may help to point out that OI2 isn't a _product_, but a > _project_. Asking product questions (e.g. "Does it do A") can be useful, but > not nearly as much as asking project questions (e.g. "Can someone help me write > feature A" or "How can we make it easy for someone to write the A > feature"). OI2 might be a project but that does not mean that every piece of code written on OI2 should part of that project. OI2 is an excellent platform to extend in the direction of your needs, but those developer needs which aren't already addressed by OI2 are hardly ever general enough to be used by most people who might benefit from building their application on OI2. For this we have packages and an excellent management framework. The questions from the people who are interested in OI2 are more probably going to be: "How easy does using OI2 makes it for me to do A?" and "Has someone already done A on OI2 and could I benefit from it?" and thus these are also the questions we should be thinking when we develop OI2. A huge part of addressing the first question id to provide a clear, detailed mission statement and a bug repository + documentation stating which features are missing or buggy and need more work. The second question can be addressed by providing a repository of easy to use packages or compilations of packages, which can be adapted or extended to your specific needs. Answering to the second question is IMO not part of actual OI2 development, but it is a vital part for OI2 to success as an application platform. I think we should make it an another project which would build OI2 packages that provide different functionality and then compile a demonstration application(s) from these packages for OI2. I think this is the best way we can help OI2 to advance as a project since the more people write their applications on OI2, the more we can identify places where OI2 should be developed futrher to achieve our mission - and we will probably even get help for doing it. I think that if OI2 has no clear mission, everybody will concentrate more on building their own missions and OI2 will always remain just half made everything. > OI2 is an open source project, dammit. Why bother with the self-scrutinizing > philosophical questions when we can change the world with code? We _have_ the > freedom to do watever we want, and _that_ is why I'm sure you can mold OI2 into > whatever you want it to be... :-) Open source project is just like any other project: to succeed it needs good management. Lonesome coders hacking away as they see fit is not going to end up being everything we all need. We need to discuss the directions where we are going so that we can benefit on each others work. I can write a million hello worlds within an hour by using OI2 and some code generation, but it is not going to change the world. > Chris, is it feasible to give people access to improve the website? To suddenly change the mission statement the way one wants it instead of discussing it with all the others first? ;) > What's more important? That new users and developers can get a site up and > running easily, or that experienced developers have a "clean install" to > work from? In my opinnion both are important and they are in no way conflicting goals. Ofcourse it is very important to have example code or even an example system you can build upon if it _happens_ to fit your needs. But building upon the example code should IMO not be the expected usage. I think the expected usage should be that you pick a collection of the example modules you need and build your application using those. > Should OI2 _only_ be an application framework, or should it also be usable > ("out-of-the-box") as a corporate intranet? Or a collaboration tool for a > volunteer organization? Or a generic frontend for a database? Should we be > allowed to choose? I think OI2 should be _only_ an application framework. Simply said. I think that if you have built up a corporate intranet on top of OI2 you should name it OpenInteract2 Corporate Intranet and publish the compilation of packages you have used in a different site or a project hosting OI2 apps, which OI2 site can then link to so that those building their own corporate intranets can have almost out of the box functionality, but those who are building a frontend for database don't have to mind their head if they can remove your corporate intranet package XY from their fresh website install without breaking the whole system. There are unlimited uses of OI2 and many of them DO conflict with each other. This is why none of them should be included in OI2 base install but somewhere else. >> Although the lower level functionality is important, sometimes these also do >> not serve the purposes. > (A little off topic here: I think it would have been _much_ better if you > improved OI2 instead of replacing parts of it. :) What do you mean by improving OI2? We have only 2 patches against the OI2 cvs tree, of which one is already obsolete because of the changes in OI2 tree and the other is already reported in JIRA and is being discussed - we can't just go and commit the code before discussing with Chris even if we have commit access to CVS. Then we have our own version of many of the factory classes in OI2, but even many of those changes are either discussed on the dev list or reported in JIRA as change suggestions. Then we have some packages which are used to test some approaches and which in the end _might_ end up into OI2 as ideas, but are currently implemented so that they are not near generally usable. On the other hand they might provide to be immense crap. Also there is lots of code which will never find it's way into OI2 because it's application specific. I very much doubt that Chris would want our bloated security framework into OI2 since the whole structure is heavily dependent on our applications view on groups and users and we ignore SPOPS securities for management reasons. If somebody, for some reason, needs similiar group and security implementation, they are very welcome to check what we have done. It's in the CVS and it's very liberally licenced. But it definately is not a general approach that should be provided as the default one for OI2. On top of our specific focus, we have limited resources and tight schedules, like everybody in this business has. We just simply don't have the time to plan and test our approaches as long as we find a way that might be integratable with OI2. Usually the good ideas grow in time and they need a lot of experimenting in different directions to evolve to a general state. We can't just decide that we will make everything as general as possible to be incorporated into OI2 core even if we wanted to. We do what we can given the resources, but usually the output is far from general and reusable Brick. When it evolves, maybe? But the sad fact is that we can't dump the customers who pay our bread to go on a crusade to build a better world - we are already making as many stabs as we can towards that goal. For example we are not just trying to persuade you to see OI2 as solely an application framework just because we use it as one. We think that it would be the right thing to do for most of OI2's users. > Just do it... > > For example, find the parts of Dicole which are (almost) general enough for > everybody to use, and find a way to move it out of Dicole and into OI2 > instead. What makes you think that we are not doing it the best we can? The abundance of my oi-dev posts? ;) We can't just decide ourselves that OI2 needs this and that and completely wreck the CVS without asking anyone. We have to discuss and agree about things - like the things we are talking about in this mail thread. - Antti |
From: Salve J N. <sal...@me...> - 2005-07-18 16:37:13
|
Teemu Arina wrote: >>> Well what I was thinking was more in the lines of OI2 not being even >>> partly a CMS. >> >> I'm sure you can mold OI2 into whatever you want it to be... :-) > > I believe that for a project to become _the_ option for a certain target > audience, it should state it's mission and roadmap pretty clearly. This > builds up confidence in the platform and provides an answer to the most > important question: ok if we start to use it now, how is it going to improve > and in which direction? > > Answering, that it can be anything you want it to be is pretty confusing. Argh. I was trying to avoid the public relations discussion... :-\ I'll try to rephrase a little.. Basicly I agree with you, but I also think the question of "wether or not OI2 is a CMS (or has a clear end-user decipherable mission statement)" isn't the most important question at this stage. Today, I think we're much better off if we try to make OI2 as developer-friendly as possible. To do this, it may help to point out that OI2 isn't a _product_, but a _project_. Asking product questions (e.g. "Does it do A") can be useful, but not nearly as much as asking project questions (e.g. "Can someone help me write feature A" or "How can we make it easy for someone to write the A feature"). If we hace a quick look at the state of OI2 (today), it may look something like this - AFAICT: 1) OI2 is Big and Complicated 2) Although the beta period for OI2 has lasted forever(tm), there's still a large amount of bugs (currently around 60 in JIRA). :-\ 3) OI2 has some good "infrastructure" features but few "application" features. Developers like the former, users the latter. Who's more important? 4) OI2 is pretty well documented (I'm guessing 75%), but lacks a lot of common things that make large amounts of information more comprehensible to the reader (e.g. ER diagrams, class diagrams, data flow diagrams). 5) The OI2 community is too small and quiet. :-( 6) Contribution to the project is difficult - perhaps due to social quirks (shyness of speaking in public fora? our inability to follow up requests on this mailing list? the "Jante law"?), but also due to technical complexity (finding where to add a feature requires a lot of digging). 7) One _can_ say OI2 has a lacking webpage, unclear about mission and perspective. 8) We have an underutilized wiki (is anyone actually reading or using it?) 9) The mailing list archives and bugtracker have little sense of connection between them, the website and the wiki. What can we do to make all this information less fragmented? Is there a way we could integrate JIRA with the main site? Or use a OI2-native wiki instead of TWiki? 10) We have only a vague sense of what kind of audience OI2 is for. It seems to be mainly for advanced web application developers, but we'd like more people to use it, right? 11) Chris has always been doing most of the significant development, but like the rest of us, he's swamped in distractions from from doing the Important Stuff - namely improving OI2. :) All these points lead to interesting project questions. Ask yourself these questions, find if some of them interest you, try to answer these, and finally try to implement the answer. (And should you come across something that stops you from implementing it, then fix that first) OI2 is an open source project, dammit. Why bother with the self-scrutinizing philosophical questions when we can change the world with code? We _have_ the freedom to do watever we want, and _that_ is why I'm sure you can mold OI2 into whatever you want it to be... :-) > Let's revisit openinteract.org first paragraph. Let's call it the mission > statement: [deletia] Sure. Fix it if you have access, write a bugreport if you haven't. Chris, is it feasible to give people access to improve the website? > So if it's intended as a base for web application development, then why on > earth does it require you to install an CMS you might have no use for? What's more important? That new users and developers can get a site up and running easily, or that experienced developers have a "clean install" to work from? Should OI2 _only_ be an application framework, or should it also be usable ("out-of-the-box") as a corporate intranet? Or a collaboration tool for a volunteer organization? Or a generic frontend for a database? Should we be allowed to choose? > All the other functionality, like security, user/group management, UI > widgets etc. are very important for web application development. Higher or > more specific implementations should be optional. Sure. Sounds reasonable. If they're not optional, they at least have to be easy to uninstall, and doing that shouldn't break anything. > Although the lower level functionality is important, sometimes these also do > not serve the purposes. We replaced/extended most of the > user/group/security stuff in our OI2 application called Dicole (demo at > http://dicole.net) > > [...] (A little off topic here: I think it would have been _much_ better if you improved OI2 instead of replacing parts of it. :) >> They're there so you can get a notion of what's possible to do OI2, and >> when you've seen _that_, the _real_ big questions show up: How can I use >> OI2? How can I improve OI2? What should be improved? How easy is it to >> improve OI2? How can I make it easier to improve OI2? What should be >> improved so OI2 becomes easier to improve? > > These questions can be answered if the base installation greets you as a web > application framework and not as a generic CMS. Sure. Fix it if you have access, write a bugreport if you haven't. > Despite some things I'm not happy with, OI2 is still the best decision we > have made when we looked for a new base to build upon. We have done more > during this time for our customers than we could have done without. The > design of the web application framework is brilliant and I'm happy to help > it to be even better. Just do it... For example, find the parts of Dicole which are (almost) general enough for everybody to use, and find a way to move it out of Dicole and into OI2 instead. This would in the long run mean less maintainance, more user feedback for you (assuming OI2 becomes as wildly popular as we'd like :) ) and more out-of-the-box and Good Stuff to impress people with. :) (Enough ranting! I realize I may be a bit boastful for someone who's contributed as little as I have, but please ignore this fact and see if any of my points are valid anyway. :) - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |