Re: [perldoc2-developers] General Questions

[Joergen W. L. <joe...@gm...>]

[This (not Roberts preceding) post should be mostly obsolete since most 
of it should be answered in the Specification. Anyway - for 
completeness' sake... here we go:]

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 future
>> growth and extensibility it is probably the wiser choice to go more for
>> the "application" way of things.

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

It should be clear by now, that other document formats should be not a 
big problem, thanks to po4a (Nicolas' posting) and CPAN (Herbert's posting).

> 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. This
> 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?

see Spec and the following discussion.

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

The translation of the "core documentation" is a "subproject" of the 
translation of the Perl documentation, for example. See Spec for details.

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

I was referring to forums that run on the platform or as part of is. The 
data accumulated by these forums will probably be stored in one or the 
other DB. This DB should be easily maintainable.

With "resources" I meant things like glossaries that might be available 
to transalators or other people. Maybe people could have their own 
glossary or dictionary.

CPAN is a resource but none that is maintained by this project so it 
probably does not count in this context.

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

-T comes to mind. The things you mention above could probably be 
incorporated in some sort of "coding guideline" for the project. For the 
moment I do not think, we need this, since the people involved had 
enough time to learn from their own mistakes already, right? ;o))

>> - stableness
>>    (same as above)
> 
> I can't really remember any stability issues with the current popular Perl
> web frameworks, anyway.

Do they stay up and running even if one or more required modules fail to 
work (maybe due to an update, API change or whatever)? Especially with 
these huge lists of dependencies this could be an issue. But maybe I'm 
just paranoid.

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

This might be important if we start developing the platform on SF and 
then have to move it to whatever the final destination might be.

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

Agreed.

Joergen