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

Re: [Openinteract-dev] working on packages in place

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

> Apologies for the newbie question but... How do the rest of you work on OI2 packages?  Do you
keep exporting and installing them every time you make a change, or do you edit them in place
after the initial install? I'm assuming the latter, but the docs seem to suggest one should
install it again every time.

If I make a lot of changes I re-install the package. If I only change the actions, then I just use
a script to copy the .pm files from a package to the tmplib directory of the website, which is
faster than a reinstall. This makes sense if you work with CVS.

-- 

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
FLOSS in education blog: http://flosse.dicole.org

[Openinteract-dev] working on packages in place

[Perrin H. <pe...@el...>]

Apologies for the newbie question but... How do the rest of you work on
OI2 packages?  Do you keep exporting and installing them every time you
make a change, or do you edit them in place after the initial install?
I'm assuming the latter, but the docs seem to suggest one should install
it again every time.

- Perrin

AW: [Openinteract-dev] More on: Preloading of everything

[<And...@Be...>]

Hi Antti,

We are still into OI1 and see similar behavior since we are using quite =
a lot of packages. Actually we hoped, that OI2 would show a different =
behavior - maybe s.o. has an idea ?


Cheers

Andreas

-----Urspr=FCngliche Nachricht-----
Von: ope...@li... =
[mailto:ope...@li...]=20
Gesendet: Sonntag, 19. Juni 2005 17:02
An: ope...@li...
Betreff: [Openinteract-dev] More on: Preloading of everything


After a good night sleep I came to the conclusion that maybe providing a =

way not to preload everything is not very urgent and it might be good to =

delay it for a 2.x release.

But to give you some idea of what kind of benefits you might get from=20
not preloading everything, I did some poking around with a stick on =
Dicole.

By default the main apache thread takes up 61 Mb on startup. Leaving =
languages (2 full and one paritial) uninitialized frees ~1 Mb. Leaving =
SPOPS objects uninitialized frees ~3 Mb. Leaving Actions uninitialized =
frees ~27 Mb.

If all of these are left uninitialized, the main apache thread takes up=20
28,5 Mb. If the whole Context is left uninitialized, the main thread=20
takes up 23,5 Mb, so only about 5 Mb of Context is not in these three =
parts.

I also noticed that building the Setup hierarchy does a require on all=20
of the Setup classes and this, with their dependencies, seems to use=20
something like 6 Mb of space - much of which might be possible to avoid=20
and which is probably not used after startup.

I'm not really sure if OI2 will ever be really usable with CGI though.=20
Even if the required initialization could be dropped somewhere close to=20
25 Mb, after leaving the 7 mb of mod_perl apache, it still leaves 18 Mb=20
of modules to be initialized on each request. But it would still be nice =

to have a bit smaller apache threads when having multiple OI2=20
installations on the same machine and use CGI when developing, so that=20
one would not have to restart apache after each change.

- Antti


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies =
from IBM. Find simple to follow Roadmaps, straightforward articles, =
informative Webcasts and more! Get everything you need to get up to =
speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
openinteract-dev mailing list ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev

[Openinteract-dev] More on: Preloading of everything

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

After a good night sleep I came to the conclusion that maybe providing a 
way not to preload everything is not very urgent and it might be good to 
delay it for a 2.x release.

But to give you some idea of what kind of benefits you might get from 
not preloading everything, I did some poking around with a stick on Dicole.

By default the main apache thread takes up 61 Mb on startup.
Leaving languages (2 full and one paritial) uninitialized frees ~1 Mb.
Leaving SPOPS objects uninitialized frees ~3 Mb.
Leaving Actions uninitialized frees ~27 Mb.

If all of these are left uninitialized, the main apache thread takes up 
28,5 Mb. If the whole Context is left uninitialized, the main thread 
takes up 23,5 Mb, so only about 5 Mb of Context is not in these three parts.

I also noticed that building the Setup hierarchy does a require on all 
of the Setup classes and this, with their dependencies, seems to use 
something like 6 Mb of space - much of which might be possible to avoid 
and which is probably not used after startup.

I'm not really sure if OI2 will ever be really usable with CGI though. 
Even if the required initialization could be dropped somewhere close to 
25 Mb, after leaving the 7 mb of mod_perl apache, it still leaves 18 Mb 
of modules to be initialized on each request. But it would still be nice 
to have a bit smaller apache threads when having multiple OI2 
installations on the same machine and use CGI when developing, so that 
one would not have to restart apache after each change.

- Antti

[Openinteract-dev] More on: Preloading of everything

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

After a good night sleep I came to the conclusion that maybe providing a 
way not to preload everything is not very urgent and it might be good to 
delay it for a 2.x release.

But to give you some idea of what kind of benefits you might get from 
not preloading everything, I did some poking around with a stick on Dicole.

By default the main apache thread takes up 61 Mb on startup.
Leaving languages (2 full and one paritial) uninitialized frees ~1 Mb.
Leaving SPOPS objects uninitialized frees ~3 Mb.
Leaving Actions uninitialized frees ~27 Mb.

If all of these are left uninitialized, the main apache thread takes up 
28,5 Mb. If the whole Context is left uninitialized, the main thread 
takes up 23,5 Mb, so only about 5 Mb of Context is not in these three parts.

I also noticed that building the Setup hierarchy does a require on all 
of the Setup classes and this, with their dependencies, seems to use 
something like 6 Mb of space - much of which might be possible to avoid 
and which is probably not used after startup.

I'm not really sure if OI2 will ever be really usable with CGI though. 
Even if the required initialization could be dropped somewhere close to 
25 Mb, after leaving the 7 mb of mod_perl apache, it still leaves 18 Mb 
of modules to be initialized on each request. But it would still be nice 
to have a bit smaller apache threads when having multiple OI2 
installations on the same machine and use CGI when developing, so that 
one would not have to restart apache after each change.

- Antti

[Openinteract-dev] Preloading of everything

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

Hello everyone :) It's been pretty quiet lately, but at least our 
project with OI2 has not stopped. I personally have grown to like OI2 
more and more as I use it and would like to start using it also on some 
smaller projects than Dicole. For smaller projects it is not however 
very easy to justify the amount OI2 requires memory and I would like to 
touch the issue of preloading everything at startup. There are at least 
two problems with preloading everything:

1. At the moment, OI2 is completely unusable as CGI because it takes 
several seconds on a fast machine to initialize Context fully. This is a 
shame since otherwise OI2 works with CGI as well as it does on mod_perl, 
FastCGI and the daemon.

2. Multiple installations of OI2 require that they are running on 
different Apaches, which means completely different perl interpreters, 
which means multiplication of all the code in memory. This could be 
acceptable if the memory footprint was not so huge and huge amounts of 
it were not polluted during the first request.

On single, heavily resourced installations the current approach works - 
and works very nicely. But with smaller resources, limited environment 
or multiple installations this might not always be the best option.

Thus I think that it would be nice to have an option not to fully 
initialize the Context but still maintain it fully functional on 
request. On many occasions trading speed for lower memory usage or 
faster startup time could be welcome.

It is at the moment already possible to easily leave some portions of 
Context uninitialized because this was needed to speed up oi2_manage, 
but at the moment this means also that some of the functionality is lost.

One major time & space hog is preloading of all actions. This is done 
for most actions already when the action table is assigned to CTX since 
we need to gather actions dispatch url data (and thus requiring them 
separately afterwards seems to be useless?). Could we gather this 
dispatch url data (or the whole action table?) separately before Context 
initialization and place it in a "cached" repository? Normal mod_perl 
server start could invoke this generation before startup, but for CGI 
this could be done by hand after each setup/override modifications or 
package installs. Action's init_at_startup() would probably also need to 
be rethought.

Other noteworthy task is preloading of SPOPS objects. In fact it seems 
that at the moment you can already skip InitializeSPOPS and things "just 
work" :) (I haven't tested this yet). This just leaves the gathering of 
all spops config data which could be handled similarily as the action table.

Also one could leave some languages unintialized even though this isn't 
_currently_ a major timesaver. It will be one in the future since I'm 
pretty sure we are going to have way over 10 different localizations 
eventually. This I have not investigated much but could guess that it 
would be possible to actually pregenerate the classes that OI2 now 
generates and evaluates at startup and require them only when needed.

So is there some fundamental problem that I have missed that makes some 
of this impossible? To me it seems that the OI2 infrastructure is so 
well built that this could be done with relatively small changes, but 
since I can't say that I see the real picture perfectly, I would welcome 
some input from Chris - at least in theoretical level ;)

When it comes to managing different types on initializations I think we 
could use the recently added dependency builder. Instead of running all 
setup actions by default, one could specify what setup actions are run 
and then everything that those packages are dependent on would also run. 
One could then craft different metapackages with dependencies for 
different types of startups.

What do you all think about this? Am I the only one who would like a 
"light weight" OI2?

- Antti

[Openinteract-dev] About the Action class

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

I have filed a improvement request in JIRA on some improvements but 
after some more concideration I'd like to have some discussion on the 
Action class in general..

Maybe my needs are a bit odd. I want to manually create an action so 
that I personally specify things like language and additional parameters 
in addition to action and task. I would want this action to respect the 
environment I give to it and not use anything found in CTX->request.

A quick look in the Action class seems to indicate that relatively few 
places in the action depend on CTX->request but they are vital parts 
like additional assigning, language handle (and thus $action->_msg), 
message passing from request, checking cache (because of an admin check 
and cache params in request) and fetching parameters from request.

I think that is would be good if as much of this dependency would be 
cleared out so that one can determine how an action is executed without 
having a tweaked CTX->request handy. I think that most (if not all) of 
the data needed could be assigned to various keys in the action upon 
it's creation.

Also after this, could it be possible to find out the task and 
additional parameters before execute?

Now they are all being gathered in execute and it is thus pretty hard to 
do any security checks, or anything else, before the determined task is 
executed. So when you create an Action, it is pretty much a black box 
and you can just fire execute off and see what happens, since you can't 
know which task it chooses to execute and thus which additional 
parameters it will have set..

So what do you think?

- Antti

Re: [Openinteract-dev] lookup_action error

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

Oh. I just noticed that there was a url_none which can be used to 
prevent action from being executed directly by a request. No need for a 
none-controller then :)

But I'm still not sure about the error on lookup failure..

- Antti

[Openinteract-dev] lookup_action error

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

Hi!

CTX->lookup_action not just dies (which is ok) but logs an OpenInteract2 
error if the action is not found. I personally would not like it to log 
an error and not even give a warning - I would like it to be a debug or 
info message, but i might be misusing OI2. What do you think?

I have action xxyy which returns a datastructure in our package Y but 
package Y is not required for functional system.  Other packages which 
would use action xxyy lookup for that action and if it does not exist 
they just don't use the functionality, which is ok since the 
functionality was not required.

I have understood that actions are an abstraction layer provided for 
functionality which can be defined by any package, so i don't know what 
other mechanism i should use to detect if a functionality exists or not.

I did not make this a bug report since i'm not quite sure if this is the 
intended way of using OI2 actions.

- Antti

PS. It would probably be nice to have a "null" or "none" controller by 
default which would not let the action to execute when called directly 
from a request.. If this is a decent way to handle things..

[Openinteract-dev] Is it a bug in SPOPS::DBI version 3.23?

[Pronichev A. <dy...@ag...>]

I add a caching mechanism to SPOPS (using memcached daemon+Cache::Memcached perl module to it's API). And I think I found a bug in SPOPS::DBI in fetch method. The skip_cache key is added to $p hashref even if object hasn't been founded in cache, so our SPOPS objects (derived from SPOPS::DBI) never will be cached. The diff is attached. Am I right or not?

Thanks.
-- 
WBR dyker
Agava Software

[Openinteract-dev] serializing fields in SPOPS

[Pronichev A. <dy...@ag...>]

Hi, I would like to add such behavior to my SPOPS::DBI objects:
For example a have an SQL table

id INT PRIMARY KEY,
login CHAR(20),
data BLOB

I want to have a spops config like this: 
my $config = {
	obj => {
		isa => ['SPOPS::DBI::MySQL'...],
		class => 'My::SPOPS::User',
		field => ['login', 'password', 'email',...],
		serialize => ['password', 'email'],
		serialize_to => 'data',
		...
	}
}
and when I call my $obj = My::SPOPS::User->new(); $obj->{password}='..'; $obj->{email}='...'; $obj->save; I want that all fields in 'serialize' key were serialized (by Storable for example) and serialized data were stored in 'data' field of table (from serialize_to config key). And similarly when I fetch() object I would like that 'serialized' object fields were deserialized and I have an access to them like to regular fields.
The point is that I am newbie to SPOPS and I would like to do it in best way. I think I have to write a ruleset and create post_fetch_action, pre_save_action to serialize/deserialize data.

Thanks.

-- 
WBR dyker
Agava Software

[Openinteract-dev] SPOPS::DBI question

[Pronichev A. <dy...@ag...>]

Hi.
Firstly I'm not a native speaker...and I'm newbie to SPOPS :). 

I need my SPOPS object to 'fetch'() like this: 
- I call Object->fetch_group(.....);
- Before fetch()ing objects I must make a request to some daemon and pass to daemon fetch() arguments;
- Daemon determine a dsn, user, password for each object that meet this sql statement and return it to me;
- I have to fetch() each object, with right dbi connect.

Who can suggest me a right way to do it? I think that I must create a SPOPS::SQLInterface subclass, that override all db_* methods to make request to daemon and after that call my parent methods with right $dbh. Am I right or no?

Thanks.

-- 
WBR dyker
Agava Software

[Openinteract-dev] OI2 lists on Gmane

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

Hi!

The openinteract-help and openinteract-dev lists are now available on 
Gmane.org. This means (among other things) that messages to the list can 
be read with your favourite USENET client or through Gmane's spiffy web 
interface (which is quite a bit better than Sourceforge's IMHO :)

   http://dir.gmane.org/gmane.comp.lang.perl.modules.openinteract.general
   http://dir.gmane.org/gmane.comp.lang.perl.modules.openinteract.devel

BTW, do any of you know of any complete (downloadable) archives of the 
lists? Gmane works fine as a searchable archive too, if we want it to. :)


- 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] any Class::DBI users with current OI2 install?

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

I've got a working version of glue between Class::DBI and OI2. 
Unfortunately it requires a modification (small) to one of the classes 
from 1.99_06 to support the 'RootClass' attribute when creating a DBI 
handle. (I'd never heard of that before...) 'Unfortunately' because I 
was really hoping to get this out before _07 and requiring a CVS 
version for a CPAN dependency is bad form. Oh well.

So if you've got an OI2 (1.99_06) install are familiar with CDBI (my 
knowledge is now a few hours old) and are willing to test a little, let 
me know.

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988

AW: [Openinteract-dev] OI2 under mod_perl2

[Kutter M. <mar...@si...>]

Hi Chris,

The attached file contains a bunch of modules I modified or added to
OI1.99_04 to make it running with Apache2 (and some other numerous
changes...).

I still use CGI for creating Apache2 requests, as the libapreq package =
which
provides Apache::Request is not stable yet (and changes with almost =
every
new mod_perl Revision).

CGI >=3D 3 is required for Apache2.

I've modified the login process in the Apache*::OpenInteract packages,
because I use http authentication via apache, so maybe you have to =
change
this.

My startup script for Apache2 is also attached.

Regards,

Martin Kutter

-----Urspr=FCngliche Nachricht-----
Von: 'Chris Winters' [mailto:ch...@cw...]
Gesendet: Mittwoch, 23. M=E4rz 2005 16:57
An: Kutter Martin
Betreff: Re: [Openinteract-dev] OI2 under mod_perl2


* Kutter Martin (mar...@si...) [050323 10:49]:
> Hi Chris,
>=20
> I can offer my (somewhat modified) copy of OI 1.99_04
>=20
> It runs fine under Apache2 (I have modified / rewritten the=20
> Request handler and some other stuff).
>=20
> Unfortunately, I won't have the time to condense everithing into some =

> fine patch for the next few month.
>=20
> The current stuff is just a bunch of modules which differ=20
> from the original OI2 sources.

That would be great!

I need to get your SOAP stuff in there too -- I haven't forgotten.

Chris

--=20
Chris Winters (http://www.cwinters.com)
Building enterprise-capable snack solutions since 1988

Re: [Openinteract-dev] Bricks

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

On Mar 23, 2005, at 10:26 PM, Teemu Arina wrote:
>> The 'package_class' reference is supposed to be a OI2::App class 
>> rather
>> than a OI2::Brick class. (I'll update the docs to clarify.)
>
> is there a simple way to create this OI2::App out of a package 
> directory?

Umm... I did have a script to do this but I don't think I included it. 
Let me see... ah, I do have the script I used for all the OI2 packages. 
Basically it processes sample/package/App.pm, generates the right 
package name and class name, and replaces [% pod %] with the 
docs/foo.pod. It's very simple but you're welcome to it.

I doubt it will be useful to many other folks since all packages 
created from now on with oi2_manage will have this by default.

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988

Re: [Openinteract-dev] New website

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

On Mar 23, 2005, at 10:17 PM, Teemu Arina wrote:
> Yea I got Camtasia studio and have created several screencasts already
> as user manuals for software I've created. Works nice and a lot more 
> informative
> compared to 100's of pages of manuals.

I agree: showing is a lot better than telling.

> We also need a video of Chris throwing a presentation of the OI2 
> architecture.
> Is your software able to show slides and you narrating on top of that 
> stuff?

I'm not sure... I'll have to see.

> Part of success seems to be the way they got their selves on the nerve 
> pulse
> of the blogger community. They had a nice low-level platform and also a
> nice high-level implementation, Basecamp on top of it. I remember 
> reading about
> it in some high-traffic blogs. Of course every blogger featured 
> basecamp because it's
> basically a specialized blogging tool, mainly for projects. The top 
> bloggers are
> meta-bloggers (blogging about blogging) anyway.

Right. I actually had an idea that we could implement an internal 
blogging system/aggregator for the place I work and think it would be 
incredibly useful. But it's not at all in my work scope.

The idea that you've got one or two useful apps out of the box is very 
powerful though. And we've actually got an implementation for one of 
the buzzwords (lightweight tagging/folksonomies) in the 
'delicious_tags' package, which will almost certainly get moved into 
_07 as an 'object_tags' package. Tagging everything is pretty nifty.

> I see if I can give it a shot in a few months if I have the time (the 
> usual problem).

I hear that. Although the 'we need you!' wasn't just aimed at Teemu, it 
was to everyone :-)

> Any top-class designers or OI2 coders here? I suggest it's based on a 
> wiki, a static
> front page and some weblog tool for the latest news. RSS feeds, 
> obviously. OI has
> everything but the wiki, but well that's not really required, although 
> it would be
> nice for tutorials etc. Is the current twiki how easy to modify (to 
> just match the look of
> the new website, for example) and does it work without the camel case
> (i.e. [[New website|NewWebsite]])?

I really dislike TWiki -- it's just so crufty. (And I say that having 
written a few plugins for it.) I started working on a wiki package a 
while ago but didn't have time to see it though -- I'll see what kind 
of shape that's in. I would like to have a more structured area of the 
site though -- IME wiki works well for support/FAQ/ideas but not as 
much as an introduction.

> Maybe we can fix that XHTML interface of OI at the same time? =)

Absolutely. That reminds me -- I meant to shoot Chris Nandor an email 
about this to see if he's got some guidelines because he's been doing 
the same to Slashcode recently:

   http://use.perl.org/~pudge/journal/23723

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988

Re: [Openinteract-dev] Bricks

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

> The 'package_class' reference is supposed to be a OI2::App class rather
> than a OI2::Brick class. (I'll update the docs to clarify.)

is there a simple way to create this OI2::App out of a package directory?

If not, where is the example on how to create one?

- Teemu

Re: [Openinteract-dev] New website

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

> I had the same idea and grabbed a video capture tool a short while
> ago; maybe I'll try it out tonight... :-)

Yea I got Camtasia studio and have created several screencasts already
as user manuals for software I've created. Works nice and a lot more informative
compared to 100's of pages of manuals.

We also need a video of Chris throwing a presentation of the OI2 architecture.
Is your software able to show slides and you narrating on top of that stuff?

> Seriously, I'm very impressed by how quickly they've got everyone
> talking about Rails. Part of the reason is that Ruby is on everyone's
> "I need to learn that" list and part is that they make easy things
> really easy. (I haven't heard as much about how well tough things go,
> but I wouldn't underestimate them.) They've also got conference
> heavyweights like Dave Thomas pushing, a big deal.

Part of success seems to be the way they got their selves on the nerve pulse
of the blogger community. They had a nice low-level platform and also a
nice high-level implementation, Basecamp on top of it. I remember reading about
it in some high-traffic blogs. Of course every blogger featured basecamp because it's
basically a specialized blogging tool, mainly for projects. The top bloggers are
meta-bloggers (blogging about blogging) anyway.

> I think another thing we can do is get a number of useful applications
> ready-to-go as well as framework enhancers like
> OI2::Action:RSS. Leveraging CPAN for this helps us a lot.

> Redesigning the website is an area where I'll be overjoyed to
> delegate. (As anyone who has seen my website knows, my design sense is
> very limited.) Of course, simpler is better.
>
> So if you've got some free time and design skills, we need you!

I see if I can give it a shot in a few months if I have the time (the usual problem).
Any top-class designers or OI2 coders here? I suggest it's based on a wiki, a static
front page and some weblog tool for the latest news. RSS feeds, obviously. OI has
everything but the wiki, but well that's not really required, although it would be
nice for tutorials etc. Is the current twiki how easy to modify (to just match the look of
the new website, for example) and does it work without the camel case
(i.e. [[New website|NewWebsite]])?

Maybe we can fix that XHTML interface of OI at the same time? =)

-- 

Teemu Arina, CTO

Ionstream Oy / Dicole
Komeetankuja 4 A
02210 Espoo
FINLAND
Tel: +358-(0)50 - 555 7636
skype: infe00
Corporate website: http://www.dicole.com
FLOSS in education blog: http://flosse.dicole.org
Personal weblog: http://infedelic.blogspot.com

"Discover, collaborate, learn."

Re: [Openinteract-dev] Bricks

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

On Mar 23, 2005, at 9:55 PM, Teemu Arina wrote:
> I've got a slight problem with Bricks. I have now successfully ported
> my stuff on OI2 1.99_06 and everything seems to work ok.

Cool.

> I made an installer for debian that grabs available packages from
> apt and installs the rest from my home-made .deb packages, even OI2
> now that it is based on bricks.
>
> For my own application I wanted to do a similar thing by creating 
> Bricks.
> But I keep getting the following:
>
> # oi2_manage install_package 
> --package_class=OpenInteract2::Brick::DicoleBase
> [oi2_manage]: Caught exception during task execution
> [oi2_manage]: Factory type [] is not defined in 
> [OpenInteract2::Brick::DicoleBase]

The 'package_class' reference is supposed to be a OI2::App class rather 
than a OI2::Brick class. (I'll update the docs to clarify.) The 
'package_class' functionality was implemented for the 
CPAN-distributable packages rather than using the bricks directly -- 
the difference is that CPAN-distributable packages have the .pm files 
outside the brick and that everything in the brick is stored as-is.

But it makes some sense to make this available -- particularly since 
we'll need to distribute updates to the core packages -- so I'll add a 
'--brick_class' to the package installer.

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988

[Openinteract-dev] Bricks

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

I've got a slight problem with Bricks. I have now successfully ported
my stuff on OI2 1.99_06 and everything seems to work ok.

I made an installer for debian that grabs available packages from
apt and installs the rest from my home-made .deb packages, even OI2
now that it is based on bricks.

For my own application I wanted to do a similar thing by creating Bricks.
But I keep getting the following:

# oi2_manage install_package --package_class=OpenInteract2::Brick::DicoleBase
[oi2_manage]: Caught exception during task execution
[oi2_manage]: Factory type [] is not defined in [OpenInteract2::Brick::DicoleBase]

The generated code of my brick looks identical to other Bricks, just the package name
and embedded base64 stuff is different (obviously). I used the same build_bricks
script you use to create the stock packages. I thought there is something wrong
with my packages, but:

oi2_manage install_package --package_file=dicole_base-0.01.zip

...works just fine.

Any ideas?

- Teemu

Re: [Openinteract-dev] New website

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

(cc'd to -help since more folks are there)

* Teemu Arina (te...@io...) [050323 18:43]:
> We need a new website for OpenInteract. Something that kicks ass ==
> clean but visual design, grabs your attention in first 2 minutes and
> has a nice image / videos / screencasts so that you crasp the core
> idea faster than you say SPOPS.

I had the same idea and grabbed a video capture tool a short while
ago; maybe I'll try it out tonight... :-)

> Excellent example (atleast, we need the architecture chart and the FAQ):
> http://www.rubyonrails.com/

Those RoR people are everywhere!

Seriously, I'm very impressed by how quickly they've got everyone
talking about Rails. Part of the reason is that Ruby is on everyone's
"I need to learn that" list and part is that they make easy things
really easy. (I haven't heard as much about how well tough things go,
but I wouldn't underestimate them.) They've also got conference
heavyweights like Dave Thomas pushing, a big deal.

I think another thing we can do is get a number of useful applications
ready-to-go as well as framework enhancers like
OI2::Action:RSS. Leveraging CPAN for this helps us a lot.

Redesigning the website is an area where I'll be overjoyed to
delegate. (As anyone who has seen my website knows, my design sense is
very limited.) Of course, simpler is better.

So if you've got some free time and design skills, we need you!

Chris

-- 
Chris Winters (http://www.cwinters.com)
Building enterprise-capable snack solutions since 1988

[Openinteract-dev] New website

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

We need a new website for OpenInteract. Something that kicks ass == clean but visual
design, grabs your attention in first 2 minutes and has a nice image / videos
/ screencasts so that you crasp the core idea faster than you say SPOPS.

Excellent example (atleast, we need the architecture chart and the FAQ):
http://www.rubyonrails.com/

What do you say?

-- 

Teemu Arina, CTO

Ionstream Oy / Dicole
Komeetankuja 4 A
02210 Espoo
FINLAND
Tel: +358-(0)50 - 555 7636
skype: infe00
Corporate website: http://www.dicole.com
FLOSS in education blog: http://flosse.dicole.org
Personal weblog: http://infedelic.blogspot.com

"Discover, collaborate, learn."

Re: [Openinteract-dev] Experiences with OI2 1.99_06

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

* Teemu Arina (te...@io...) [050323 11:00]:
> Actually I don't. Just noticed they are removed (docs not updated!). I used
> them in several places for various reasons in my code and I had to change the
> code to just get that stuff out of url_relative. I think it's cleaner
> now, I think request has nothing to do with actions anyway.

They'll be updated shortly, sorry about that.
 
> url_relative and url_absolute include the GET parameters now. Nice, now I can
> work with the state as I proposed a long time ago. I used those also as something
> like:
> 
> $url = CTX->request->url_relative . '/help';
> 
> If the URL includes GET parameters, that piece of code obviously doesn't work anymore
> as it did previously. Thinking aloud: No problem with that, I can always strip the GET
> parameters when I use it like that so a GETless accessor is not
> really required.

Yeah, if you think it's useful to have a non-param version of the URL
we can add it in there.

> > My mp2 experience is lacking as well.
> 
> This is still important, some distros like Fedora include (I think?)
> only Apache2.

Absolutely. Just a matter of finding time...
 
> Nothing wrong with the parser, it works ok. This null entry just breaks the
> TT stuff you already suggested to fix.


Ok.
 
> That's great. While you are at it, change the OI2 stock .msg file
> parser to read keys that have spaces etc. in them as well.

Yep, good idea.

>... 
> One thing with this. If the requested translation is:
> 
> Hello [_1]!
> 
> If a translation is found, it gets replaced something like:
> 
> Hello John!
> 
> But if the key is returned (no translation found) that [_1] is not replaced.
> I think this is perfectly ok, although we could just add something like this:
> 
> $key =~ s/\[_(\d+)\]/\%$1/g;
> return sprintf( $key, @params );

Good idea.

(Implementation note: will that work? The resulting %1, %2... do not
seem like valid sprintf syntax... Regardless, the intent is clear.)

Chris 

-- 
Chris Winters (http://www.cwinters.com)
Building enterprise-capable snack solutions since 1988

Re: [Openinteract-dev] Experiences with OI2 1.99_06

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

>> 1.
>> task_name and action_name are not anymore in CTX->request. Is there
>> other way to access those through the context?
>
> Why do you need them? I thought of keeping them in the request after
> implementing the ActionResolver but couldn't think of a good
> reason. (And that's not saying there isn't one.)

Actually I don't. Just noticed they are removed (docs not updated!). I used
them in several places for various reasons in my code and I had to change the
code to just get that stuff out of url_relative. I think it's cleaner
now, I think request has nothing to do with actions anyway.

url_relative and url_absolute include the GET parameters now. Nice, now I can
work with the state as I proposed a long time ago. I used those also as something
like:

$url = CTX->request->url_relative . '/help';

If the URL includes GET parameters, that piece of code obviously doesn't work anymore
as it did previously. Thinking aloud: No problem with that, I can always strip the GET
parameters when I use it like that so a GETless accessor is not really required.

> My mp2 experience is lacking as well.

This is still important, some distros like Fedora include (I think?) only Apache2.

> The PO parsing is done entirely in Locale::Maketext::Lexicon::Gettext,
> so if there's a bug in the parsing we should probably let them know.

Nothing wrong with the parser, it works ok. This null entry just breaks the
TT stuff you already suggested to fix.

>   - create classes for all supported languages
>   - assign keys/values directly into created class
>
> That way there should be no modification of the original variable and
> it will maintain its utf8 (or other) metadata.

That's great. While you are at it, change the OI2 stock .msg file parser to read
keys that have spaces etc. in them as well.

I'm commiting the following as I now received feedback on them:

>> Also, my patch removes unnecessary dublicate key errors.

>> lib/OpenInteract2/I18N.pm
>> Changes the system so that instead of returning "Message error for '$key'"
>> it returns the key itself in case no translation is found.

One thing with this. If the requested translation is:

Hello [_1]!

If a translation is found, it gets replaced something like:

Hello John!

But if the key is returned (no translation found) that [_1] is not replaced.
I think this is perfectly ok, although we could just add something like this:

$key =~ s/\[_(\d+)\]/\%$1/g;
return sprintf( $key, @params );

>> lib/OpenInteract2/Request.pm
>> OI2 always selects the language provided by the browser (user agent). Well, it was a bit
>> difficult to change the language as a user, because it had no effect ;)
>> I changed this chain to something more logical:
>>
>> Changes the order in how the language is selected:
>>  - prefers $lang_config->{choice_param_name} over user or session language
>>  - prefers user and session language over user agent provided languages
>>  - prefers everything else over $lang_config->{default_language}

-- 

Teemu Arina, CTO

Ionstream Oy / Dicole
Komeetankuja 4 A
02210 Espoo
FINLAND
Tel: +358-(0)50 - 555 7636
skype: infe00
Corporate website: http://www.dicole.com
FLOSS in education blog: http://flosse.dicole.org
Personal weblog: http://infedelic.blogspot.com

"Discover, collaborate, learn."