Re: [perldoc2-developers] General Questions

[Robert 'p. S. <rs...@47...>]

Hello Joergen, 'evening .*

Joergen W. Lang said:
> Robert 'phaylon' Sedlacek schrieb:
>
>> * Service or Application?
>
> The initial idea was to have a platform dedicated mainly (but not
> exclusively) to the perl community. So to prepare the project for futur=
e
> growth and extensibility it is probably the wiser choice to go more for
> the "application" way of things.
>
> I think, generally it is a good idea to be as open to other projects as
> possible. On the other hand, there is Rosetta
> (https://launchpad.net/rosetta) which aims at more or less the same
> goals (and also uses gettext/.po). It already has a huge user/translato=
r
> base plus *very* solid funding. Rosetta is part of the Ubuntu project.
>
> The major difference between Rosetta and our project is our focus on
> documentation rather than dialogues, program messages, etc.
>
> Having said this, I guess that Rosetta can still be a good source of
> inspiration. Analyzing their approach is another piece of work I will
> have to do...

Well, I actually had only the perl community in mind at first, as most of
them will have documentation in POD format.

> Interestingly enough we actually have a working platform already: the
> SVN repository on sourceforge. It is just not really useable by 'end
> users', aka translators.
>
> Frank Seitz of Hamburg.pm suggested a while ago a database driven
> approach. That might be more maintainable/extensible than the SVN-based
> approach.
>
> Any SQL experts around?

It all depends on what we "want to do." Personally, I'd ++ a database
approach with a, for example, shipped DBIC model that's ready to use. Thi=
s
would allow 3rd parties to develop tools which can flow back to the
project.

What approach or schema to take depends on the data structure. What atoms
are there for checkout/editing/comparing/merging/etc? What workflows have
to be there, which states have to be kept?

> As the platform (or - at least the 'interface') will be mostly web-base=
d
> this is going to be a key decision. I think the choice should be based
> on the following:

As I'm really only familiar with Catalyst, I'll focus my answers in this
part on it.

> - extensibility
>    (add natural and programming languages, subprojects...)

What do you mean by "subprojects"? Most Perl Frameworks will provide
support for Unicode and I18N/L10N. And if we focus on po4a as input
format, we have a common middle ground that can be targetted by other
documentation projects/formats.

> - maintainability
>    (database, forums, resources)

Catalyst itself is database-agnostic. Personally I'd favor DBIC, as it is
pretty expressive, powerful, and has a very active community. I'm not so
sure what you mean with forums and resources. Does CPAN count for the
latter?

> - security
>    (the more people use it, the bigger the chance that someone
>    breaks it accidentally)

Well, if we don't eval, check all incoming user data, use database access
based somehow on DBI and it's binding mechanisms, we should be on a save
side. Fortunately, we have no register_globals :)

> - stableness
>    (same as above)

I can't really remember any stability issues with the current popular Per=
l
web frameworks, anyway.

> - simpleness
>    (both in structure as in useability)

Good point. I'd like to add deployability, where Catalyst itself has pro'=
s
and con's. The con part is it's huge list of dependencies, but that can
(in a ready application) be shipped with, either in a distribution or in =
a
PAR file, which should be able to capture the whole perl deployment
environment.

Another pro is the possibility of deployment on many engines. mod_perl,
FastCGI, SpeedyCGI, pperl.


Thanks for the answers!
gr.,
Robert

--=20
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail =3D> ' rs...@47... ', Web =3D> ' http://474.at ' }