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

Re: [Openinteract-dev] A few extensions to SPOPS and a comment on the PODs

[Andrew S. H. <ste...@ci...>]

There's a complete rewrite of SPOPS in progress?  Hmm.  I haven't seen 
anything inside SPOPS that would really warrant that, but I don't know 
why this rewrite is happening.  In generally, I just meant that the 
internals of SPOPS could be better segmented out.  I've been toying 
with Ray Zimmerman's SPOPSx::Ginsu plugin and looking through that 
source, he's done an excellent job of commenting which points he had to 
modify the code copied from various methods.  Basically, I was thinking 
that the internals of each method should be broken up as seems 
appropriate to allow someone to replace only parts.

Right now, there are only 2 internal method calls for fetch_group({}) 
in SPOPS::LDAP!  This is astounding for the amount of code that's 
there.  Most other projects I've examined would have had a half dozen 
or more at the minimum for a piece of code like this.

As for my Active Directory solution, I'll attach it to an email to the 
list when I get to work so you can see what I've done.  The features 
I've added are:

1.  The ability to set a custom "sizelimit".
2.  Using VLV controls to get all the records requested.  (This also 
requires the use of Sort, so I have an "order" option.)
3.  A custom SPOPS::Iterator::ActiveDirectory which allows you to start 
iterating through the records before all have been collecting (much 
better on long queries).
4.  I hacked in a not_objectclass setting which basically does the 
opposite of the objectclass setting.  I think this would be better as a 
query_template option where you could say: query_template => 
"(&(!(objectclass=Computer))(objectclass=__OBJECTCLASS__)(__QUERY__))".

If the solution is to be integrated into SPOPS::LDAP, then more work 
needs to be done.  Should let the user determine whether the sizelimit 
enforcement is done with the Paged control or the VLV control.  And 
some other clean up needs to be done.

Regards,
Sterling

On Sep 8, 2004, at 3:47 AM, Kutter Martin wrote:

> Hi Andrew !
>
> In one case you are damn right: SPOPS requires hacking the SPOPS.pm 
> module
> for writing additional backends. In my opinion, this is a design flaw 
> that
> should be removed - hence I don't have collected any idea about this 
> by now.
>
> I guess your AD module is more or less a rewrite of SPOPS::LDAP. I've 
> been
> hacking on SPOPS::LDAP for some time now - removing bugs and adding
> functionality like returning sorted results - maybe this would be 
> something
> to merge with you changes and hand it back as a rewritten SPOPS::LDAP.
>
> As far as I know, Vsevolod (Simon) Ilyushchenko is working on a 
> complete
> SPOPS rewrite - maybe our ideas are something to integrate for him.
>
> My opinion from hanging on this list is, that Chris - though building
> wonderful software - is packed with work up to the roof, so he just 
> doesn't
> have the time to re-work subprojects like SPOPS (And he doesn't have 
> an LDAP
> server handy - ain't that so ?).
>
> So, Chris - maybe you would like to "outsource" SPOPS::LDAP 
> maintenance for
> a while ?
> If someone else would join me, I'd offer to take over SPOPS::LDAP
> maintenance for a limited time (say, a year).
>
> Regards,
>
> Martin Kutter
>
> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On Behalf Of 
> Andrew
> Sterling Hanenkamp
> Sent: Montag, 6. September 2004 04:40
> To: ope...@li...
> Subject: [Openinteract-dev] A few extensions to SPOPS and a comment on
> the PODs
>
>
> I have a couple things, first I've come up with a new extension for
> SPOPS to allow it to connect to and communicate with Active Directory
> properly.  I mentioned this idea on openinteract-help, but that list is
> apparently dead.  The major difference is that it uses queries with the
> VLV control rather than plain queries because Active Directory sharply
> limits the sizelimit of LDAP queries.  I also added a couple minor
> features to allow the exclusion of an objectClass because Microsoft
> believes that Computers are Users.
>
> I thought I'd mention that in case the SPOPS developers would like to
> comment or see the code before I upload it to CPAN.  I have a few other
> smaller modules for manipulating data in some nice ways that I may also
> release on CPAN.
>
> I've also been digging through the innards of SPOPS and it ain't
> pretty.  The basic extension interface is really elegant, but if
> someone wants to build or extend a driver (such as my Active Directory
> extension or SPOPSx::Ginsu), then he's got some serious code hacking
> ahead of him.  I was wondering if there was any interest in patching up
> the internals of SPOPS to make it more easily extensible and more
> manageable.  I think the framework is already elegant enough that such
> changes could really make SPOPS awesome.  If some of the internals were
> a little better specified and a few more divisions added, extensions
> could concentrate on smaller pieces of the puzzle.
>
> My final comment is that the SPOPS documentation is evil.  It's spread
> far and wide, has too many bugs, and contradictions.  For example, the
> Object-Rules specify that rules should not modify the columns, but then
> SPOPS comes with several Tool modules which do exactly that
> (SPOPS::Tool::DateConvert is the most egregious).
>
> Anyway, it seems to me that SPOPS is a little stagnate, but I think it
> beats the pants off of the likes of Class::DBI and Alzabo.  I'd like to
> help in these areas as I can.  I've got a project where I'm planning to
> use SPOPS pretty heavily, so it'll be to my benefit to make sure SPOPS
> does what I need and I'll have to extend it in a couple more spots, so
> I might as well give back to the project while I'm at it.  This project
> will probably last for the duration of my current job, so this could
> involve some long term interest (multiple years) as well.
>
> Cheers,
> Sterling
> --
> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><>
>   Andrew Sterling Hanenkamp
>   System Administration Manager
>   Computing & Information Sciences
>   Kansas State University
>
>   http://www.cis.ksu.edu/~sterling/
>   ste...@ci...
>
>    It's not that perl programmers are idiots, it's that the language
>    rewards idiotic behavior in a way that no other language or tool
>    has ever done.                              -- Erik Naggum
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> openinteract-dev mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openinteract-dev
>
>
--
<>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><>
  Andrew Sterling Hanenkamp
  System Administration Manager
  Computing & Information Sciences
  Kansas State University

  http://www.cis.ksu.edu/~sterling/
  ste...@ci...

   It's not that perl programmers are idiots, it's that the language
   rewards idiotic behavior in a way that no other language or tool
   has ever done.                              -- Erik Naggum

AW: [Openinteract-dev] Small i18n issue

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

.. DBD::Oracle is even worse: if you have a LANG environment with =
UTF8, then
the NLS_LANG Oracle stuff breaks and leads to weird error messages...

Mit freundlichen Gr=FC=DFen
Andreas Nolte=20
Leitung IT
-------------------------------------------------
arvato direct services
Olympiastra=DFe 1
26419 Schortens
Germany
http://www.arvato.com/
and...@be...
Telefon +49 (0) 44 21 - 76-84002
Telefax +49 (0) 44 21 - 76-84111



-----Urspr=FCngliche Nachricht-----
Von: ope...@li...
[mailto:ope...@li...]=20
Gesendet: Mittwoch, 8. September 2004 11:56
An: ope...@li...
Cc: Kutter Martin; 'ope...@li...'
Betreff: Re: [Openinteract-dev] Small i18n issue



> I've been able to track this down to a charset problem.
> LDAP expects directoryString attributes to be in UTF-8 encoding. The=20
> perl-ldap interface (Net::LDAP) does not provide UTF-8 conversions by =

> default, so these are to be done by the application using Net::LDAP.=20
> This is no big deal - just a
>
>  use Encode;
>  $value =3D decode($charset, $value);

I had a similar problem with DBD::mysql and UTF-8. DBI has no general =
policy

for UTF-8, so it has to be implemented by DBD:s themselves. DBD::mysql =
does=20
nothing to that issue. If you store UTF-8 strings in the database and=20
retrieve them back, these strings do not get marked as UTF-8. Later it =
might

happen that your UTF-8 strings get encoded as UTF-8, because Perl =
didn't
mark=20
those as UTF-8 already =3D) Encode module helps fixing this problem for
example=20
in SPOPS::DBI::MySQL (define a post_fetch_action() that converts all =
data=20
fields).

I wonder when you are able to write utf-8 compatible software without
mocking=20
all the internals on several layers... It has been around so many years =
and=20
still many module writers ignore it. It also wasn't until mysql 4.x =
when
they=20
included UTF-8 support in character type fields.

> The problem is, that the only available solution to get the charset=20
> used in the request is to grab it from the underlying Apache::Request =

> or CGI::Request handle - not really easy and not really portable:
>
>  my $contentHeader =3D CTX->request->apache->headers_in()->{=20
> Content-Type };

I noticed the same thing. I also found another way to set it:

CTX->response->content_type( 'text/html; charset=3Dutf-8' )

CTX->response->charset() would be nice to have.

Greetings,

- Teemu


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
openinteract-dev mailing list ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev

RE: [Openinteract-dev] Small i18n issue

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

Hi Andreas,

This looks like the default solution. Unfortunately, =
SPOPS::Tool::UTFConvert
always assumes iso-8859-a (Latin1) as originating charset, which is not
neccessarily true.

So, this does not work for charsets other than Latin1. The ability to =
grab
the charset from the request in conjunction with a slightly modified
SPOPS::Tool::UTFConvert ( use the request's charset, if given) would =
remove
the problem completely.

Regards,

Martin Kutter

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of
And...@Be...
Sent: Mittwoch, 8. September 2004 11:53
To: ope...@li...
Subject: AW: [Openinteract-dev] Small i18n issue


Hi Martin,

We had the same problem with reading Umlaut characters with LDAP for =
the
user names. You can solve this by adding the following to the =
spops.perl
file of the package in question:

  rules_from =3D> [ 'SPOPS::Tool::UTFConvert' ],

Hope that helped...

Mit freundlichen Gr=FC=DFen
Andreas Nolte=20
Leitung IT
-------------------------------------------------
arvato direct services
Olympiastra=DFe 1
26419 Schortens
Germany
http://www.arvato.com/
and...@be...
Telefon +49 (0) 44 21 - 76-84002
Telefax +49 (0) 44 21 - 76-84111



-----Urspr=FCngliche Nachricht-----
Von: ope...@li...
[mailto:ope...@li...]=20
Gesendet: Mittwoch, 8. September 2004 11:33
An: 'ope...@li...'
Betreff: [Openinteract-dev] Small i18n issue


Hi * !

I ran into a small internationalization issue, today.=20
I'm running a OI2 site with SPOPS::LDAP as backend. On storing =
non-ASCII
characters in the LDAP directory server, this complains that properties =
with
non-ASCII-characters have an "invalid syntax".

I've been able to track this down to a charset problem.=20
LDAP expects directoryString attributes to be in UTF-8 encoding. The
perl-ldap interface (Net::LDAP) does not provide UTF-8 conversions by
default, so these are to be done by the application using Net::LDAP. =
This is
no big deal - just a=20

 use Encode;
 $value =3D decode($charset, $value);

for all the fields to set - but one needs to know the request's =
charset.

The charset used in the HTTP request is specified by the "charset" =
attribute
in the Content-Type header.=20

Example:

Content-Type: multipart/formdata; boundary=3D"--------------12345";
charset=3D"EUC-JP"

The default is "iso-8859-1" if no charset is supplied.=20

The problem is, that the only available solution to get the charset =
used in
the request is to grab it from the underlying Apache::Request or
CGI::Request handle - not really easy and not really portable:

 my $contentHeader =3D CTX->request->apache->headers_in()->{ =
Content-Type };

As different charsets in HTTP requests are very likely to happen in =
i18n'ed
environments, and the problem is very likely to occur in non-LDAP
environments, too, I would suggest an extension to the
OpenInteract2::Request class, that provides access to the Content-Type =
HTTP
header, like it already does with some other header fields.

Maybe even a more general approach - exposing all HTTP headers in the
request object - could be suitable: This would remove the need to react =
on
additional HTTP headers by code changes forever.

Regards,

Martin Kutter


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
openinteract-dev mailing list ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dclick
_______________________________________________
openinteract-dev mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev

Re: [Openinteract-dev] Small i18n issue

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

> I've been able to track this down to a charset problem.
> LDAP expects directoryString attributes to be in UTF-8 encoding. The
> perl-ldap interface (Net::LDAP) does not provide UTF-8 conversions by
> default, so these are to be done by the application using Net::LDAP. This
> is no big deal - just a
>
>  use Encode;
>  $value = decode($charset, $value);

I had a similar problem with DBD::mysql and UTF-8. DBI has no general policy 
for UTF-8, so it has to be implemented by DBD:s themselves. DBD::mysql does 
nothing to that issue. If you store UTF-8 strings in the database and 
retrieve them back, these strings do not get marked as UTF-8. Later it might 
happen that your UTF-8 strings get encoded as UTF-8, because Perl didn't mark 
those as UTF-8 already =) Encode module helps fixing this problem for example 
in SPOPS::DBI::MySQL (define a post_fetch_action() that converts all data 
fields).

I wonder when you are able to write utf-8 compatible software without mocking 
all the internals on several layers... It has been around so many years and 
still many module writers ignore it. It also wasn't until mysql 4.x when they 
included UTF-8 support in character type fields.

> The problem is, that the only available solution to get the charset used in
> the request is to grab it from the underlying Apache::Request or
> CGI::Request handle - not really easy and not really portable:
>
>  my $contentHeader = CTX->request->apache->headers_in()->{ Content-Type };

I noticed the same thing. I also found another way to set it:

CTX->response->content_type( 'text/html; charset=utf-8' )

CTX->response->charset() would be nice to have.

Greetings,

- Teemu

AW: [Openinteract-dev] Small i18n issue

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

Hi Martin,

We had the same problem with reading Umlaut characters with LDAP for =
the
user names. You can solve this by adding the following to the =
spops.perl
file of the package in question:

  rules_from =3D> [ 'SPOPS::Tool::UTFConvert' ],

Hope that helped...

Mit freundlichen Gr=FC=DFen
Andreas Nolte=20
Leitung IT
-------------------------------------------------
arvato direct services
Olympiastra=DFe 1
26419 Schortens
Germany
http://www.arvato.com/
and...@be...
Telefon +49 (0) 44 21 - 76-84002
Telefax +49 (0) 44 21 - 76-84111



-----Urspr=FCngliche Nachricht-----
Von: ope...@li...
[mailto:ope...@li...]=20
Gesendet: Mittwoch, 8. September 2004 11:33
An: 'ope...@li...'
Betreff: [Openinteract-dev] Small i18n issue


Hi * !

I ran into a small internationalization issue, today.=20
I'm running a OI2 site with SPOPS::LDAP as backend. On storing =
non-ASCII
characters in the LDAP directory server, this complains that properties =
with
non-ASCII-characters have an "invalid syntax".

I've been able to track this down to a charset problem.=20
LDAP expects directoryString attributes to be in UTF-8 encoding. The
perl-ldap interface (Net::LDAP) does not provide UTF-8 conversions by
default, so these are to be done by the application using Net::LDAP. =
This is
no big deal - just a=20

 use Encode;
 $value =3D decode($charset, $value);

for all the fields to set - but one needs to know the request's =
charset.

The charset used in the HTTP request is specified by the "charset" =
attribute
in the Content-Type header.=20

Example:

Content-Type: multipart/formdata; boundary=3D"--------------12345";
charset=3D"EUC-JP"

The default is "iso-8859-1" if no charset is supplied.=20

The problem is, that the only available solution to get the charset =
used in
the request is to grab it from the underlying Apache::Request or
CGI::Request handle - not really easy and not really portable:

 my $contentHeader =3D CTX->request->apache->headers_in()->{ =
Content-Type };

As different charsets in HTTP requests are very likely to happen in =
i18n'ed
environments, and the problem is very likely to occur in non-LDAP
environments, too, I would suggest an extension to the
OpenInteract2::Request class, that provides access to the Content-Type =
HTTP
header, like it already does with some other header fields.

Maybe even a more general approach - exposing all HTTP headers in the
request object - could be suitable: This would remove the need to react =
on
additional HTTP headers by code changes forever.

Regards,

Martin Kutter


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
openinteract-dev mailing list ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev

[Openinteract-dev] Small i18n issue

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

Hi * !

I ran into a small internationalization issue, today. 
I'm running a OI2 site with SPOPS::LDAP as backend. On storing non-ASCII
characters in the LDAP directory server, this complains that properties with
non-ASCII-characters have an "invalid syntax".

I've been able to track this down to a charset problem. 
LDAP expects directoryString attributes to be in UTF-8 encoding. The
perl-ldap interface (Net::LDAP) does not provide UTF-8 conversions by
default, so these are to be done by the application using Net::LDAP. This is
no big deal - just a 

 use Encode;
 $value = decode($charset, $value);

for all the fields to set - but one needs to know the request's charset.

The charset used in the HTTP request is specified by the "charset" attribute
in the Content-Type header. 

Example:

Content-Type: multipart/formdata; boundary="--------------12345";
charset="EUC-JP"

The default is "iso-8859-1" if no charset is supplied. 

The problem is, that the only available solution to get the charset used in
the request is to grab it from the underlying Apache::Request or
CGI::Request handle - not really easy and not really portable:

 my $contentHeader = CTX->request->apache->headers_in()->{ Content-Type };

As different charsets in HTTP requests are very likely to happen in i18n'ed
environments, and the problem is very likely to occur in non-LDAP
environments, too, I would suggest an extension to the
OpenInteract2::Request class, that provides access to the Content-Type HTTP
header, like it already does with some other header fields.

Maybe even a more general approach - exposing all HTTP headers in the
request object - could be suitable: This would remove the need to react on
additional HTTP headers by code changes forever.

Regards,

Martin Kutter

RE: [Openinteract-dev] A few extensions to SPOPS and a comment on the PODs

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

Hi Andrew !

In one case you are damn right: SPOPS requires hacking the SPOPS.pm module
for writing additional backends. In my opinion, this is a design flaw that
should be removed - hence I don't have collected any idea about this by now.

I guess your AD module is more or less a rewrite of SPOPS::LDAP. I've been
hacking on SPOPS::LDAP for some time now - removing bugs and adding
functionality like returning sorted results - maybe this would be something
to merge with you changes and hand it back as a rewritten SPOPS::LDAP.

As far as I know, Vsevolod (Simon) Ilyushchenko is working on a complete
SPOPS rewrite - maybe our ideas are something to integrate for him.

My opinion from hanging on this list is, that Chris - though building
wonderful software - is packed with work up to the roof, so he just doesn't
have the time to re-work subprojects like SPOPS (And he doesn't have an LDAP
server handy - ain't that so ?).

So, Chris - maybe you would like to "outsource" SPOPS::LDAP maintenance for
a while ?
If someone else would join me, I'd offer to take over SPOPS::LDAP
maintenance for a limited time (say, a year).

Regards,

Martin Kutter

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of Andrew
Sterling Hanenkamp
Sent: Montag, 6. September 2004 04:40
To: ope...@li...
Subject: [Openinteract-dev] A few extensions to SPOPS and a comment on
the PODs


I have a couple things, first I've come up with a new extension for 
SPOPS to allow it to connect to and communicate with Active Directory 
properly.  I mentioned this idea on openinteract-help, but that list is 
apparently dead.  The major difference is that it uses queries with the 
VLV control rather than plain queries because Active Directory sharply 
limits the sizelimit of LDAP queries.  I also added a couple minor 
features to allow the exclusion of an objectClass because Microsoft 
believes that Computers are Users.

I thought I'd mention that in case the SPOPS developers would like to 
comment or see the code before I upload it to CPAN.  I have a few other 
smaller modules for manipulating data in some nice ways that I may also 
release on CPAN.

I've also been digging through the innards of SPOPS and it ain't 
pretty.  The basic extension interface is really elegant, but if 
someone wants to build or extend a driver (such as my Active Directory 
extension or SPOPSx::Ginsu), then he's got some serious code hacking 
ahead of him.  I was wondering if there was any interest in patching up 
the internals of SPOPS to make it more easily extensible and more 
manageable.  I think the framework is already elegant enough that such 
changes could really make SPOPS awesome.  If some of the internals were 
a little better specified and a few more divisions added, extensions 
could concentrate on smaller pieces of the puzzle.

My final comment is that the SPOPS documentation is evil.  It's spread 
far and wide, has too many bugs, and contradictions.  For example, the 
Object-Rules specify that rules should not modify the columns, but then 
SPOPS comes with several Tool modules which do exactly that 
(SPOPS::Tool::DateConvert is the most egregious).

Anyway, it seems to me that SPOPS is a little stagnate, but I think it 
beats the pants off of the likes of Class::DBI and Alzabo.  I'd like to 
help in these areas as I can.  I've got a project where I'm planning to 
use SPOPS pretty heavily, so it'll be to my benefit to make sure SPOPS 
does what I need and I'll have to extend it in a couple more spots, so 
I might as well give back to the project while I'm at it.  This project 
will probably last for the duration of my current job, so this could 
involve some long term interest (multiple years) as well.

Cheers,
Sterling
--
<>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><>
  Andrew Sterling Hanenkamp
  System Administration Manager
  Computing & Information Sciences
  Kansas State University

  http://www.cis.ksu.edu/~sterling/
  ste...@ci...

   It's not that perl programmers are idiots, it's that the language
   rewards idiotic behavior in a way that no other language or tool
   has ever done.                              -- Erik Naggum



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
openinteract-dev mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev

Re: [Openinteract-dev] status and gmail invites

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

Chris Winters wrote:
> 
> I expect to get back into OI development in the next week or so and hope 
> to answer all those emails and JIRA issues shortly.

Excellent! I hope things will be more quiet for you from now on.. :)


- Salve, who already has a gmail-account and five invites to give away.

-- 
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] status and gmail invites

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

> I expect to get back into OI development in the next week or so and
> hope to answer all those emails and JIRA issues shortly.

Hooray, congratulations for the new job and let's hope for a good Q4 for 
OI2 ;)

> Also, if you've been curious about this gmail (Google Mail) stuff but
> haven't had an invite: the first six people who email me will get one.
> If nothing else it's a pretty good interface for mailing lists -- I've
> got all my non-OI lists on it :-)

Count me in =)

- teemu

[Openinteract-dev] status and gmail invites

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

Hi all,

Apologies for my quietness as of late. Fortunately:

    quiet !~ /^(dead|disinterested)$/

Lots of real life turmoil that's mostly settling down right now. Part 
of this is having to look for a new job due to my current company's 
downsizing. Finding a job has taken up lots of time but it's been 
pretty successful and I'm going to be picking from a few job offers 
tomorrow. (All java jobs -- nothing's perfect.)

I expect to get back into OI development in the next week or so and 
hope to answer all those emails and JIRA issues shortly.

Also, if you've been curious about this gmail (Google Mail) stuff but 
haven't had an invite: the first six people who email me will get one. 
If nothing else it's a pretty good interface for mailing lists -- I've 
got all my non-OI lists on it :-)

Later,

Chris

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

[Openinteract-dev] A few extensions to SPOPS and a comment on the PODs

[Andrew S. H. <ste...@ci...>]

I have a couple things, first I've come up with a new extension for 
SPOPS to allow it to connect to and communicate with Active Directory 
properly.  I mentioned this idea on openinteract-help, but that list is 
apparently dead.  The major difference is that it uses queries with the 
VLV control rather than plain queries because Active Directory sharply 
limits the sizelimit of LDAP queries.  I also added a couple minor 
features to allow the exclusion of an objectClass because Microsoft 
believes that Computers are Users.

I thought I'd mention that in case the SPOPS developers would like to 
comment or see the code before I upload it to CPAN.  I have a few other 
smaller modules for manipulating data in some nice ways that I may also 
release on CPAN.

I've also been digging through the innards of SPOPS and it ain't 
pretty.  The basic extension interface is really elegant, but if 
someone wants to build or extend a driver (such as my Active Directory 
extension or SPOPSx::Ginsu), then he's got some serious code hacking 
ahead of him.  I was wondering if there was any interest in patching up 
the internals of SPOPS to make it more easily extensible and more 
manageable.  I think the framework is already elegant enough that such 
changes could really make SPOPS awesome.  If some of the internals were 
a little better specified and a few more divisions added, extensions 
could concentrate on smaller pieces of the puzzle.

My final comment is that the SPOPS documentation is evil.  It's spread 
far and wide, has too many bugs, and contradictions.  For example, the 
Object-Rules specify that rules should not modify the columns, but then 
SPOPS comes with several Tool modules which do exactly that 
(SPOPS::Tool::DateConvert is the most egregious).

Anyway, it seems to me that SPOPS is a little stagnate, but I think it 
beats the pants off of the likes of Class::DBI and Alzabo.  I'd like to 
help in these areas as I can.  I've got a project where I'm planning to 
use SPOPS pretty heavily, so it'll be to my benefit to make sure SPOPS 
does what I need and I'll have to extend it in a couple more spots, so 
I might as well give back to the project while I'm at it.  This project 
will probably last for the duration of my current job, so this could 
involve some long term interest (multiple years) as well.

Cheers,
Sterling
--
<>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><>
  Andrew Sterling Hanenkamp
  System Administration Manager
  Computing & Information Sciences
  Kansas State University

  http://www.cis.ksu.edu/~sterling/
  ste...@ci...

   It's not that perl programmers are idiots, it's that the language
   rewards idiotic behavior in a way that no other language or tool
   has ever done.                              -- Erik Naggum

AW: [Openinteract-dev] Help! Back to the wall...

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

Hi Greg,

Chris Winters told me, that he does not have time for OI2 because of
personal issues for a few weeks. I cannot imagine, that he will ever =
drop
the project.

At our company - arvato - we have been using OI1 for a few years and =
are
constantly developing new apps for it. We have also tested OI2 and plan =
to
migrate to OI2 at some point. Currently we have about 10 developers who =
are
skilled to develop for OI.

For CMS: I do not think that it would be very hard to build a CMS for =
OI2.
Even the standard install has a very limited basic CMS - the base_page. =
We
are currently working on a system we call ROMA, which is an object =
linking
system with full text search, which we integrate with our workflow =
framework
NATS zu do content management for our intranet.

If you want to start a new project with Workflows, though - I`d =
recommend
using the Workflow package from CPAN, which also comes from Chris =
Winters.
This is what we will migrate to in the future and do development work =
for.

Even if Chris would drop OI, we would stay with the software and try to =
keep
it going...

Mit freundlichen Gr=FC=DFen
Andreas Nolte=20
Leitung IT
-------------------------------------------------
arvato direct services
Olympiastra=DFe 1
26419 Schortens
Germany
http://www.arvato.com/
and...@be...
Telefon +49 (0) 44 21 - 76-84002
Telefax +49 (0) 44 21 - 76-84111



-----Urspr=FCngliche Nachricht-----
Von: Greg Fenton [mailto:gre...@ya...]=20
Gesendet: Montag, 23. August 2004 21:36
An: ope...@li...
Betreff: [Openinteract-dev] Help! Back to the wall...


So I'm fighting a losing battle on the corporate-politics front.

We are adopting a CMS for our corporate website (getting away from =
static
HTML).  I want to build a system on top of OI/OI2.  But I've been =
stymied on
a few fronts.

Is OI2 development stalled at this point?  Is anyone building new apps =
on
top of OI2 yet?

If I can't get some footholds into OI2 within the next week or so, the =
other
team members will likely go to an "existing" OSS CMS (none of which =
really
meet our needs), a commercial CMS (none of which meet our needs and =
will
cost lots 'o $$$) or a .NET solution [meaning that I walk away from the
project altogether ;-) ]

Thanks in advance,
greg_fenton.

=3D=3D=3D=3D=3D
Greg Fenton
gre...@ya...


=09
	=09
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail=20


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media =
100pk
Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% =
off
Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
openinteract-dev mailing list ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev

Re: [Openinteract-dev] Help! Back to the wall...

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

> Is OI2 development stalled at this point?  Is anyone building new apps
> on top of OI2 yet?

Well, we have been building applications on top of OI1 and now OI2 for over a 
year now and we are more than satisfied. Our latest work, soon to be released 
is Dicole, http://www.dicole.org. We have extended the application framework 
on top of OI2 for faster application development (the documentation is all on 
the site, see developer documentation). For CMS, we prefer to integrate 
something like the Mambo Open Source which is pretty good for a public 
website and all other features will run under Dicole. Dicole has almost as 
much source code as OI2, so you may imagine it is in fact a quite big 
extension to OI2.

- Teemu

Re: [Openinteract-dev] Help! Back to the wall...

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

On Mon, 2004-08-23 at 15:36, Greg Fenton wrote:
> If I can't get some footholds into OI2 within the next week or so, the
> other team members will likely go to an "existing" OSS CMS (none of
> which really meet our needs)

Depending on what your requirements are (workflow, permissions,
previewing, structured content entry, etc.), building a CMS from scratch
on OI2 might be a lot of work.  If you're interested in a well-designed
and very flexible open source CMS in Perl, check out Krang:
http://krang.sf.net/

Krang is intended to be used for publishing your content to static
files, so you could still use OI2 for any dynamic parts of your site
without trouble.

- Perrin

[Openinteract-dev] Help! Back to the wall...

[Greg F. <gre...@ya...>]

So I'm fighting a losing battle on the corporate-politics front.

We are adopting a CMS for our corporate website (getting away from
static HTML).  I want to build a system on top of OI/OI2.  But I've
been stymied on a few fronts.

Is OI2 development stalled at this point?  Is anyone building new apps
on top of OI2 yet?

If I can't get some footholds into OI2 within the next week or so, the
other team members will likely go to an "existing" OSS CMS (none of
which really meet our needs), a commercial CMS (none of which meet our
needs and will cost lots 'o $$$) or a .NET solution [meaning that I
walk away from the project altogether ;-) ]

Thanks in advance,
greg_fenton.

=====
Greg Fenton
gre...@ya...


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

RE: [Openinteract-dev] SPOPS::LDAP does not filter for objectclas s=CONFIG->ldap_fetch_ob ject_class in fetch() calls

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

Hi * !
...oops, I did a typo in the patch - it won't work as expected.

Here's the correct version.

Regards,

Martin Kutter

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of Kutter
Martin
Sent: Montag, 9. August 2004 14:26
To: 'ope...@li...'
Subject: [Openinteract-dev] SPOPS::LDAP does not filter for
objectclass=CONFIG->ldap_fetch_ob ject_class in fetch() calls


Hi * !

There's a little flaw in SPOPS::LDAP. 
On calling $class->fetch($id) a LDAP the following LDAP filter is generated:

($class->id_field=$id)

This allows multiple objects to be returned from the LDAP search in case
there are 
two ore more objects with different object classes but same values in the
id_field 
attribute of the object being fetched. 

As fetch() needs a single object returned from a search, this behaviour can
cause 
fetch() calls to fail.

More than one object in the same LDAP subtree with same values for same
attributes 
are a very common case: Just imagine the user (posixAccount) root and the
group 
(posixGroup) root.
posixAccount normally uses the uid attribute as RDN, but requires cn to be
set.
posixGroup normally uses the cn attribute as RDN - and you can't fetch any
of them 
any more.

The attached patch fixes the issue by filtering for 

(& (objectclass=$class->ldap_fetch_object_class) ($class->id_field=$id) )

Regards,

Martin Kutter

[Openinteract-dev] Small SPOPS patches

[Vsevolod (S. I. <si...@cs...>]

Chris,

Before I start playing with the has_a changes, I'd like to submit a few 
small patches that I have come up with. They potentially may break 
somebody's code, so I don't know what process you would like to go 
through. Perhaps we can talk to people who are using SPOPS and ask them 
if the changes are acceptable - you set the process. If you have no time 
now, we can do it later.

The patches are about:

1. Removing the forced lc-ing of field names (potentially most intrusive).
2. Giving the user to ability to set $p->{from} explicitly in 
linksto_fetch and DBI::_execute_multiple_record_query
3. Fixing the cache bug (which you may already have done) and returning 
the cached object itself, not its copy.

Simon
-- 

Simon (Vsevolod ILyushchenko)   si...@cs...
				http://www.simonf.com

Terrorism is a tactic and so to declare war on terrorism
is equivalent to Roosevelt's declaring war on blitzkrieg.

Zbigniew Brzezinski, U.S. national security advisor, 1977-81

[Openinteract-dev] SPOPS::LDAP does not filter for objectclass=CONFIG->ldap_fetch_ob ject_class in fetch() calls

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

Hi * !

There's a little flaw in SPOPS::LDAP. 
On calling $class->fetch($id) a LDAP the following LDAP filter is generated:

($class->id_field=$id)

This allows multiple objects to be returned from the LDAP search in case
there are 
two ore more objects with different object classes but same values in the
id_field 
attribute of the object being fetched. 

As fetch() needs a single object returned from a search, this behaviour can
cause 
fetch() calls to fail.

More than one object in the same LDAP subtree with same values for same
attributes 
are a very common case: Just imagine the user (posixAccount) root and the
group 
(posixGroup) root.
posixAccount normally uses the uid attribute as RDN, but requires cn to be
set.
posixGroup normally uses the cn attribute as RDN - and you can't fetch any
of them 
any more.

The attached patch fixes the issue by filtering for 

(& (objectclass=$class->ldap_fetch_object_class) ($class->id_field=$id) )

Regards,

Martin Kutter

[Openinteract-dev] SPOPS::LDAP does not allow "0" as a RDN

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

Hi * !

SPOPS::LDAP does not allow ID values to be "0", even though "0" is a valid
value for 
LDAP RDNs.

This is due to some lines checking for a *set* ID when building up DNs, and
checking it with 

 unless ($id_value)

This test fails when an ID value is set, but is set to a false value. 
The attached patch fixes the issue.

BTW: I would have preferred loading up the patch to the jira system, but
openinteract.org seems to have disappeared from DNS. 

Regards,

Martin Kutter

Re: [Openinteract-dev] Problem with localization keys and some localization gibberish

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

> OpenInteract2::I18N::Initializer
> On line 138:
> my ( $key, $msg ) = $line =~ /^\s*([\w\.]+)\s*=\s*(.*)$/;
> Change to:
> my ( $key, $msg ) = $line =~ /^\s*(\S.+\S)\s*=\s*(.*)$/;

Well, I noticed that this breaks up if your key has a '=' character. Well, 
sorry =) I might as well look at how to hack the PO support in which fixes 
these sort of problems instead of trying to fix this home-grown message file 
format too extensively.

Btw., if the key has a ' character (Like "I don't know"), it breaks up the 
I18N::Initializer on line 221 (btw. nice use of TT for code generation here). 
Change:
  '[% msg_key %]' => qq{[% messages.$msg_key %]},
to:
  qq{[% msg_key %]} => qq{[% messages.$msg_key %]},

Well, I wonder what happens if the message or the key has characters { or }...  
;)

Btw., I thought about the PO support a while, it would be nice if the package 
translation could be maintained as .po files under locale/ or something and 
upon package installation the .po files are compiled as .mo and put into 
usual places. Alternative option is to rely on the package maintainer to 
provide both: po files for translators, compiled mo files for the 
application.

>                 if ( /_msg\(.*?['"](.+?)['"]/ ) {

Well, this line in my script actually does not work if the string in your perl 
code contains a character ' or ".. oobs.

-- 
--------------

Teemu Arina
Dicole project
http://www.dicole.org

[Openinteract-dev] Problem with localization keys and some localization gibberish

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

Hi,

OI 1.99_04 does not accept keys for localized messages that contain
something else other than dots and alphanumerals (for example, space does not 
work).

OpenInteract2::I18N::Initializer
On line 138:
my ( $key, $msg ) = $line =~ /^\s*([\w\.]+)\s*=\s*(.*)$/;
Change to:
my ( $key, $msg ) = $line =~ /^\s*(\S.+\S)\s*=\s*(.*)$/;

.. because I prefer to have the actual english string as the key for easier 
translation:
$self->_msg( "Operation failed: [_1]", $message );

Instead of something like:
$self->_msg( "example.failed", $message );

More readable. For very long chunks of text I still prefer to use the 
translator unfriendly id key approach.

Also, current localization framework is very bad at UTF-8. As of my knowledge 
Locale::Maketext is not multibyte safe. I'm also looking forward to a more 
standard implementation of the localization message file format, i.e. GNU 
gettext framework through Locale::Maketext::Gettext or 
Locale::Maketext::Lexicon.

Implementation would require mapping bindtextdomain to packages locale/ 
directory (I would prefer that name instead of msg/), creating the directory 
structure under locale/ to follow standards (e.g. en/LC_MESSAGES/myapp.mo), 
using Locale::Maketext::* instead of Locale::Maketext and getting rid of the 
home-grown .msg reader in I18N::Initializer. Support for setting the encoding 
in package configuration would also be nice. gettext framework is multibyte 
safe, so this would help in creation of a chinese translation, for example.

Extracting messages from perl source and creating the resulting PO files that 
are Maketext compatible could be achieved easily with 
Locale::Maketext::Extract and associated script xgettext.pl.

Btw., here is a a script for extracting strings from the selected .pm sources 
and creating a file following the current format. It is not perfect. Expects 
that $self->_msg() is used at all times:

---
#!/usr/bin/perl

foreach $file (@ARGV)
{
        next unless -f $file;
        open FILE, "< $file",           or die "Can't open file $file: $!";
        $out = undef;
        while (<FILE>)
        {
                if ( /_msg\(.*?['"](.+?)['"]/ ) {
                        print $1 . " = " . $1 . "\n";
                }
        }
        close FILE                      or die "Can't close file $file: $!";
}
---

Example use would be something like:
./extract_msg_strings OpenInteract2/Action/* | sort | uniq > msg/locale-en.msg

--
Teemu Arina
Dicole project
www.dicole.org

Re: [Openinteract-dev] OI2::Config::Ini

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

> I don't care about which syntax my config files are - I just want them
> to be all of the same. And I don't like .pl files too much - they tend
> to be confused with perl scripts & the syntax is a killer for
> non-Perl-speakers.
>
> Would XML be an option ? XML config files would allow arbitrary levels
> of complexity. And while XML itself is not easy for humans, there are
> lots of XML editors which make editing really easy.

I remember that Chris pointed out you could specify your own INI file reader 
in the server.ini file soon (in the CVS, already?). This would allow the 
creation of a XML based configuration file parser. There is a problem though, 
all your .ini files (server.ini included) should be converted into XML 
equivalents.

-- 
--------------

Teemu Arina

Ionstream Oy / Dicole
Komeetankuja 4 A
02210 Espoo
FINLAND
Tel: +358-(0)50 - 555 7636
http://www.dicole.fi

"Discover, collaborate, learn."

RE: [Openinteract-dev] OI2::Config::Ini

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

Hi Antti, Hi * !

>> If multi-leveled .ini-style configuration files look appealing to you,
>> please respond & I'll post an alternative implementation handling
>> unlimited (almost) depth to this list (or to the OI2 patch manager).

>I mailed Chris a patch for "unlimited levels" several weeks ago and had 
>a conversation about the issue.

>I understood that Chris has philosophical reasons not to include such 
>a patch since understanding an ini-file with more than 3 levels of 
>hashes is hard for a human - and thus hard to write and maintain.

I agree with you & Cris that multi-level .ini files are hard to read 
for humans. Nevertheless, I do not like the idea of having different 
config file styles with different abilities - I would prefer them 
to be equal in terms of power.

>I really disagreed with the absolute limiting to 3 levels. I understood 
>his arguments but preferred to let people themselves decide wether 
>they want to use more than 3 levels. After a while of using my 
>unlimited-level-ini-parser I have begun to understand his points more 
>clearly and have converted all our own ini structures to use only two 
>levels. And I encourage you to do the same if you ever plan to let 
>anyone else modify your ini files x)

Actually, I do not care too much about human-readablity at least for the 
deeper leveled part of my .ini files. This is due to the fact that I 
use a custom SPOPS backend that needs some kind of backend description 
(much like WSDL) with arbitrary complex data structures.

My spops.ini files are auto-generated, and the more complex parts are 
not meant to be edited by hand - so that's no point to me.

>There are however some situations where SPOPS object for example can 
>not be initialized with only 3 levels.. (has_a / links_to relations 
>with custom key, and your example to name a few). I have understood 
>that handling of these structures is a bit under construction but 
>Chris suggested earlier that at least has_a and links_to would follow 
> the following syntax:
>[myspops has_a]
>OpenInteract2::MyObject = cystom_key: column_id

>I have understood that handling of has_a relations like this is in 
>the CVS for testing the concept but I myself have not yet had the time 
>to test it.. According to this syntax the configuration you would 
>probably end up with would be:

>[bla creation_security]
>u = WRITE
>g = 3: READ
>g = 2: WRITE
>w = READ

>ro g separated as ; :
>g = 3: READ; 2: WRITE

>This ofcourse does not yet work :)

>To help these transformations Chris wrote 
>OpenInteract2::Config::Initializer class which is used to convert ini 
>files values to other form upon reading. You can define your own class 
>for this purpose under [system_class] in server.ini if you wish to do 
>custom transformations.

In my opinion, this solution clobbers the .ini syntax - and it's just 
one step further and nobody knows how many there are to come in the 
future.

But if a maximum of [section subsection] is intended, that's the only 
way to go.

I don't care about which syntax my config files are - I just want them 
to be all of the same. And I don't like .pl files too much - they tend 
to be confused with perl scripts & the syntax is a killer for 
non-Perl-speakers.

Would XML be an option ? XML config files would allow arbitrary levels 
of complexity. And while XML itself is not easy for humans, there are 
lots of XML editors which make editing really easy. 

There are also lots of XML:: modules on CPAN, so implementing a .xml 
config file parser is not that hard.

> - Antti

Regards,

Martin 

Re: [Openinteract-dev] OI2::Config::Ini

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

> If multi-leveled .ini-style configuration files look appealing to you,
> please respond & I'll post an alternative implementation handling
> unlimited (almost) depth to this list (or to the OI2 patch manager).

I mailed Chris a patch for "unlimited levels" several weeks ago and had a conversation about the issue.

I understood that Chris has philosophical reasons not to include such a patch since understanding an ini-file with more than 3 levels of hashes is hard for a human - and thus hard to write and maintain.

I really disagreed with the absolute limiting to 3 levels. I understood his arguments but preferred to let people themselves decide wether they want to use more than 3 levels. After a while of using my unlimited-level-ini-parser I have begun to understand his points more clearly and have converted all our own ini structures to use only two levels. And I encourage you to do the same if you ever plan to let anyone else modify your ini files x)

There are however some situations where SPOPS object for example can not be initialized with only 3 levels.. (has_a / links_to relations with custom key, and your example to name a few). I have understood that handling of these structures is a bit under construction but Chris suggested earlier that at least has_a and links_to would follow the following syntax:
[myspops has_a]
OpenInteract2::MyObject = cystom_key: column_id

I have understood that handling of has_a relations like this is in the CVS for testing the concept but I myself have not yet had the time to test it.. According to this syntax the configuration you would probably end up with would be:

[bla creation_security]
u = WRITE
g = 3: READ
g = 2: WRITE
w = READ

ro g separated as ; :
g = 3: READ; 2: WRITE

This ofcourse does not yet work :)

To help these transformations Chris wrote OpenInteract2::Config::Initializer class which is used to convert ini files values to other form upon reading. You can define your own class for this purpose under [system_class] in server.ini if you wish to do custom transformations.

 - Antti

[Openinteract-dev] OI2::Config::Ini

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

Hi * !

I have some trouble with OI2::Config::Ini. I need more than just one
sub-level. As this is something very likely to most SPOPS config files (I
tried to convert a sample SPOPS-config file to INI style - 

{ bla => {
	...
	creation_security => {
		u => q/WRITE/,
		g   => { 3 => q/READ/ },
		w   => q/READ/,
	},
	...
}

broke my neck ), it looks like somwhat more flexible .ini-style files 
could brind some benefit to OpenInteract. 

If multi-leveled .ini-style configuration files look appealing to you,
please respond & I'll post an alternative implementation handling unlimited
(almost) depth to this list (or to the OI2 patch manager).

Regards,

Martin Kutter