openinteract-dev — For OI developers, includes project coordination and technical discussion.

[Openinteract-dev] About Controller and Action (again)

[Antti <an...@di...>]

(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

[Openinteract-dev] Back to Actions..

[<an...@io...>]

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

Re: [Openinteract-dev] Help needed fixing a bug

[<an...@io...>]

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

Re: [Openinteract-dev] Help needed fixing a bug

[<an...@io...>]

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

Re: [Openinteract-dev] Help needed fixing a bug

[Chris W. <chr...@gm...>]

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

[Openinteract-dev] Help needed fixing a bug

[<ant...@he...>]

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

Re: [Openinteract-dev] About Setup tasks

[Chris W. <chr...@gm...>]

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

Re: [Openinteract-dev] Mapping observers in packages

[<an...@io...>]

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

Re: [Openinteract-dev] Mapping observers in packages

[Chris W. <chr...@gm...>]

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

Re: [Openinteract-dev] Mapping observers in packages

[<an...@io...>]

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?

Re: [Openinteract-dev] Mapping observers in packages

[Chris W. <chr...@gm...>]

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

[Openinteract-dev] Mapping observers in packages

[<an...@io...>]

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

[Openinteract-dev] About Setup tasks

[<ant...@he...>]

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

[Openinteract-dev] Re: Patch to OpenInteract2 1.99_06

[Chris W. <chr...@gm...>]

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

Re: [Openinteract-dev] Package build info in CVS?

[Teemu A. <te...@di...>]

> 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."

[Openinteract-dev] Package build info in CVS?

[Salve J N. <sal...@me...>]

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

[Openinteract-dev] (fwd) Re: [Openinteract-commits] CVS: OpenInteract2/lib/OpenInteract2/Setup CreateTemporaryLibraryDirectory.pm,1.4,1.5

[Chris W. <ch...@cw...>]

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 -----

[Openinteract-dev] Re: [Openinteract-commits] CVS: OpenInteract2/lib/OpenInteract2/Setup CreateTemporaryLibraryDirectory.pm,1.4,1.5

[Salve J N. <sal...@me...>]

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

Re: [Openinteract-dev] RE: Further work on forms/layout (Was: RE: Building upon your "CSS-Only, Table-less Forms"?)

[Salve J N. <sal...@me...>]

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

Re: [Openinteract-dev] What is OpenInteract2 ?

[Salve J N. <sal...@me...>]

[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

Re: [Openinteract-dev] What is OpenInteract2 ?

[Chris W. <ch...@cw...>]

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

Re: [Openinteract-dev] What is OpenInteract2 ?

[Chris W. <ch...@cw...>]

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.

[Openinteract-dev] Wondering the action class.. again ;)

[<an...@io...>]

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

Re: [Openinteract-dev] What is OpenInteract2 ?

[<an...@io...>]

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

Re: [Openinteract-dev] What is OpenInteract2 ?

[Salve J N. <sal...@me...>]

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