THIS IS A BRAINSTORMING!
========================

I've tried to keep the meaning of the verbs similar to RFC jargon.

---

A website is a collection of paths.

A path can be connected to several host(names), or it can be connected to
none (global path, think joint resource across hostnames)

A path can be public or private.

A path has an ordered set (array) of blocks.

A path must be able to calculate its checksum (think ETag) based on the
combined checksum of all its blocks.

A path must be able to calulate its last modified time based on the newest
timestamp from all of its blocks.

A path must be able to calculate its expiry time based on the shortest
required expiry time from all of its blocks.

A path must be able to calculate its size based on the combined size of all
of its blocks.

A block can be dynamic or static.

A block must be able to calculate its own unique id/checksum that changes
when its (generated) product changes (for edge side includes, caching etc,
probably SHA1, MD5 or some other hashing method).

A block must be able to tell when it was last modified (for caching aswell).

A block should implement one or more methods that indicate what part of the
page it wants to work on (http header, head, body, footer, +more
[suggestions welcome] ). Think (possibly) Drupal hooks.

A block must indicate its content type because a given path can only
contain blocks that have compatible types (think http header Content-type).

A block must indicate its encoding if it is textual. UTF-8 could be a sane
default.

A block must have an identifier (probably UUID) that doesn't change
(immutable) that makes it easily adressable across instances of the system
(think synchronization/plugins).

A block must specify its expiry time (also for caching). 0 should probably
mean immediately become stale, but I'm unsure what measure we should use
here. For some sites "seconds" might be too wide, on the other hand,
Cache-Control/maxage uses seconds.

A block must specify its size in bytes (think Content-Length).

A block can contain an ordered set of other blocks (I'm not exactly sure
about this one). I'm thinking wrappers that pull in a large set of common
behaviour (think themes, plugins, blog front page etc.

Static blocks are rendered by a built-in method that uses a data structure
(hash possibly) of the above mentioned required methods. The checksum is
calculated when the block is created so that no more calculation is required
on usage. The static renderer should (maybe always) use a streaming interface to
minimize memory usage of the process. Scalar printing could be used for
small blocks (<64KB?). Static blocks are usually text, pictures, sound, video
or something else of binary nature.

IMPROVE THESE:

Owner of stuff is a principal, not a user (allows shared ownership).

A principal can be either a group or a user.

A group is a collection of users and/or groups (hierarchial).

Installation suggestions from zby:

http://www.simon-cozens.org/content/deploying-perl-web-applications

DEPLOYMENT:

We might actually approach the monumental task of building binary PAR
packages (relocatable) and use PAR::Repository to distribute these binary
packages to the end users using PAR::Repository::Client to update a local
repo for the user. This repo update could be run as a simple CGI application
that requires nothing but perl core to bootstrap a proper environment.

Suexec is required for this to work so that $HOME is set and stuff can be
deployed in the proper place with proper permissions.

Repo update should be able to pull specific versions of packages, to support
consistent views and avoid update breakage. Might consider
unstable/testing/stable branches to choose your level of stability.

There is more discussion about deployment issues in deployment.txt.

More information about deployment and PAR:

http://steffen-mueller.net/talks/appdeployment/
http://use.perl.org/~Alias/journal/40170
http://stackoverflow.com/questions/1710353/how-to-distribute-native-perl-scripts-without-custom-module-overhead
http://infotrope.net/blog/2009/12/18/cpan-fail/#comment-3165
http://search.cpan.org/perldoc?Par::Repository
http://search.cpan.org/perldoc?Par::Repository::Client
http://svn.openfoundry.org/par/misc/parClientBootstrapBootstrap.pl
http://blogs.perl.org/users/flamey/2010/07/why-so-puzzled-perl-vs-php-and-rest.html

TODO (please expand/move):

Authentication
Authorization
Auditing / logging
Distribution
Deployment (think web installer like the most popular PHP webapps, maybe
  with an automated local::lib bootstrap or something)
Data storage (database, key/value store, OODB, KiokuDB)?
Plugin deployment/distribution
Editing environment
Manipulation of paths and blocks to actually create pages.
Manipulation API for above mentioned elements.
Localization/i18n (which is a killer [bad] that makes too much stuff dynamic)
How to resolve authoritative path (or produce 404)
How to map HTTP errors to paths (so that they can be customized)
User/group/role management (Kerberos, LDAP, OpenID, SAML)
Identity management (view as guest, view as another user)
Choose a framework (or frameworks, with dispatching plugins)
Maybe use some stuff from http://weftsoar.net/~hdp/cpan/ for deployment
Ownership/permission inheritance (do as Active Directory?)

---

Notes from Theory
-----------------

A lot of what you say above about checksums is over my head, but I'm assuming
that you're trying to get at the sort of identity and versioning support
that's in Git, which is perfect.

My preliminary thoughts, in a nutshell:

* Blocks -- I like this, though I'm unsure about the term (it beats the crap
  out of Drupal's "nodes," though). Blocks are like Elements in Bricolage,
  really (including the support for recursion). These are a crucial part of
  the system. In fact, in my mind I have been thinking that there would be
  three kinds of blocks: static, cached, and dynamic.

  + Static blocks are just template includes. They don't do anything, just
    pull in content. Useful for simple things like ads and HTML head tags.

  + Cached blocks would be the most common. When an update is sent to them,
    they make the update, and then kick the code to generate the cached copy
    of the output. This cached copy is then what gets pulled in for every
    request. This avoids database and API overhead on every request.

    The best example I can think of is comments. When someone submits a
    comment, the block's API makes the appropriate database changes, and then
    calls the templating code, which generates a file with all of the comments
    in reverse chronological order. This output is then written to the file
    system to be pulled in like any other include, or else it's written to
    some sort of cache and pulled from the cache. It's stupid for a system to
    generate all of the comments to display every time a page is loaded; they
    should be written out only when something changes.

  + Dynamic blocks will generate their content for display every time they're
    called. This will be useful for, say, a scrolling list of a discussion
    that updates regularly and displays only a few items. The assumption here
    is that the content to be served will change as often or more often than
    the block is asked to output its display data.

* Templates -- I find the templating support in Drupal to be less than
  intuitive. I don't get it at all; there seem to be five ways to do
  everything, several layers to deal with, and way too many global variables.
  In my vision, each block will have one or more templates associated with it,
  let's say in Template Toolkit. The templates will have only 1 or 2 global
  objects -- the block object currently being rendered, and perhaps an object
  that's controlling the rendering process (this is very similar to how
  Bricolage does things). Everything needed is accessed through these objects
  or the CMS API (calling class methods and constructors) or any Perl that you
  can execute inside TT.

  Users can override the default behavior of templates by copying them to a
  different directory which is above the default directory in the template
  resolution path (the `INCLUDE_PATH` in TT). This gives users full control
  over the appearance of individual blocks, and they can break things up into
  other templates to include if they like.

  Furthermore, they can override the appearance of particular templates by
  placing other copies in different parts of the document root. For example, I
  might have a `/comments.tt` template in my template document root, but also
  `/sports/comments.tt` to make them look different for all requests to
  beneath the `/comments` URI.

* Installer -- We discussed this on IRC, but it could use some filling out in
  this README. I firmly believe that installing the CMS should be as easy as:

  1. Set up a supported Web server.
  2. Set up a supported database.
  3. Unzip the CMS download anywhere in the Web server document root.
  4. Edit a database configuration file with connection information (DSN,
     username, password, etc.)
  5. Open a URL in the browser to the proper URL for CMS. If you put it in
     `$DOC_ROOT/cms`, then you open the browser to http://example.com/cms.
  6. The CMS will display a configuration wizard to guide the user through
     configuring the CMS and building its database.
  7. All configuration data will be stored in the database.
  8. The doc root will be modified to have the proper permissions.

  That sounds like a lot, but it's not. There is no installing stuff from
  CPAN, no compiling, nothing. Just setup and go, with all configuration, other
  than the database DSN, via the Web browser. The app will figure out as much
  as it can, ask the user for info where necessary, and provide an an
  interface (and a REST API?) for editing that configuration.

* REST API -- The CMS should have a complete REST API. Anything you can do via
  its admin interface you should be able to do via the API. And anything you
  can do with blocks you should be able to do via the API. This means that we
  need to make it extremely easy for block authors to support the API just by
  implementing appropriate methods. In fact, the API for block modules should
  be well-defined and consistent, so that the system can just use them all in
  the same way.

* URLs - Gotta have legible URLs. Or rather, URLs should be pretty much
  anything users want them to be. If I've installed the CMS in the document
  root, a user should be able to edit a text document named `/index.mkdn` or
  `/foo/bar/2009/07/21/catalyst.txtl` and those will then translate into the
  URLs `/index.html` and `/foo/bar/2009/07/21/catalyst.html`. That is, the
  URLs for editing documents should be the same as for serving the content
  from those documents. The content type of the documents will map file name
  suffixes to content types (the above two examples would be a markdown file
  and a textile file). The templates can then use those files, converted to
  HTML (or whatever a template requires), in their output.

So I'm thinking a bit higher-level than you are, I think, very much in terms
of usability, rather than architecture (although I have some architectural
ideas, too, mostly around database access). Feel free to integrate as you deem
appropriate, or comment on stuff. I think I'd like to post these thoughts in
my blog, as well, but would appreciate your feedback, first.

---

Unrefined logs from #perlcms@irc.perl.org:
------------------------------------------

(2009-07-10 10:50:31) zby: anyway first the problems I see
(2009-07-10 10:50:36) robinsmidsrod: in fact, I'm thinking that maybe we don't need to actually choose a framework
(2009-07-10 10:50:39) zby: I think you need to choose a platform
(2009-07-10 10:50:45) zby: Mojo is interesting
(2009-07-10 10:51:00) robinsmidsrod: maybe we can just make a dispatching plugin for any of the large ones (Catalyst, Mojo, CGI::Application)
(2009-07-10 10:51:02) zby: but you'd need to find more people that use it
(2009-07-10 10:51:11) zby: I have no experience with it
(2009-07-10 10:51:21) robinsmidsrod: me neither - I have just skimmed the docs
(2009-07-10 10:51:26) zby: hmm 
(2009-07-10 10:51:36) robinsmidsrod: in fact, I'm not that experienced with catalyst either
(2009-07-10 10:51:39) zby: I am now experimenting with having the dispatcher in the controller
(2009-07-10 10:51:40) robinsmidsrod: I've just made one app with it
(2009-07-10 10:51:48) robinsmidsrod: actually, two apps
(2009-07-10 10:51:55) zby: so in theory you could reuse it in other framework
(2009-07-10 10:51:58) robinsmidsrod: one is here: photo-competitions.net
(2009-07-10 10:53:04) robinsmidsrod: because the only thing that is really framework-relevant is how to map the request/response objects and how to dispatch paths
(2009-07-10 10:53:21) robinsmidsrod: maybe it would be bound a bit more when we approach auth/authz
(2009-07-10 10:53:28) zby: Caught exception in ->ACL error rethrower "Access to competition/browse/all/index denied by rule CODE(0x470ed60) (defined at /home/vhosts/photo-competitions.com/script/../lib/PhotoComp.pm line 67)."
(2009-07-10 10:53:53) robinsmidsrod: guess I need to fix that 
(2009-07-10 10:54:01) zby: yes - the dispatching is the most framework dependant
(2009-07-10 10:54:08) zby: but there are other things
(2009-07-10 10:54:24) zby: like the upload field
(2009-07-10 10:54:29) zby: in the request object
(2009-07-10 10:54:39) zby: small things - but they crop up everywhere
(2009-07-10 10:56:12) zby: then there is auth
(2009-07-10 10:56:46) zby: I think you need to choose the framework
(2009-07-10 10:56:50) zby: to start with
(2009-07-10 10:57:07) zby: you need to write a prototype to show people
(2009-07-10 10:57:10) zby: and attract developers
(2009-07-10 10:57:47) robinsmidsrod: zby: yeah, but first I need to think about the data/dispatch model I want to use
(2009-07-10 10:57:57) robinsmidsrod: now that site works again
(2009-07-10 10:58:15) robinsmidsrod: still problems...
(2009-07-10 10:59:15) robinsmidsrod: it's just an uncaught exception because I didn't remove an url that was supposed to be hidden for guest users - it was a school project - so it's not exactly well-polished
(2009-07-10 11:00:41) zby: OK 
(2009-07-10 11:00:57) zby: I've skimmed your github readme
(2009-07-10 11:00:58) robinsmidsrod: well, it's my biggest catalyst project though
(2009-07-10 11:01:22) robinsmidsrod: what are your immediate thoughts?
(2009-07-10 11:01:29) zby: what is the difference between path and block?
(2009-07-10 11:01:40) robinsmidsrod: a path is basically an URI
(2009-07-10 11:01:52) robinsmidsrod: think of it like a key to a list of blocks
(2009-07-10 11:02:37) zby: OK - but blocks are also list of blocks?
(2009-07-10 11:02:38) robinsmidsrod: a block is a small part of the entire page that will actually render that path
(2009-07-10 11:03:04) robinsmidsrod: zby: that's the part I'm not sure about - if we should allow blocks to wrap other blocks
(2009-07-10 11:03:10) robinsmidsrod: or if it will just complicate stuff
(2009-07-10 11:03:34) zby: I would propose that it is recursive
(2009-07-10 11:03:53) robinsmidsrod: zby: yeah, that gives us much more flexibility
(2009-07-10 11:03:54) zby: but I would say that a path identifies a block
(2009-07-10 11:04:44) robinsmidsrod: hmm...interesting
(2009-07-10 11:05:02) robinsmidsrod: and then you just assume that a block, if it is static just wraps to the entire page
(2009-07-10 11:05:13) robinsmidsrod: if it is dynamic it probably includes children
(2009-07-10 11:05:42) zby: and you could also render sub-blocks
(2009-07-10 11:05:48) zby: because they would have paths
(2009-07-10 11:05:58) zby: this could be usefull for debugging
(2009-07-10 11:06:26) robinsmidsrod: rephrase that thing about sub-blocks
(2009-07-10 11:06:32) robinsmidsrod: I didn't quite get it
(2009-07-10 11:07:10) zby: you let a block contain other blocks
(2009-07-10 11:07:29) zby: i.e. sub-blocks
(2009-07-10 11:07:36) robinsmidsrod: now I remember why I was thinking that a path is a list of blocks - it's to be able to work nice towards ESI
(2009-07-10 11:07:40) robinsmidsrod: (Edge Side Includes)
(2009-07-10 11:07:56) robinsmidsrod: to allow static and dynamic blocks in the same page
(2009-07-10 11:08:18) zby: yeah - so I would say that a path leads to a block
(2009-07-10 11:08:27) zby: and that block can contain the list of sub-blocks
(2009-07-10 11:08:39) zby: this would be nicely recursive
(2009-07-10 11:09:00) robinsmidsrod: okay, how do we map this so that ESI can get to it?
(2009-07-10 11:09:15) zby: I have no experience with ESI
(2009-07-10 11:09:24) zby: give me some link - so that I'll read about it
(2009-07-10 11:09:45) zby: anyway - now I need a daughter emmergency break
(2009-07-10 11:10:02) robinsmidsrod: maybe this one? http://varnish.projects.linpro.no/wiki/ESIfeatures
(2009-07-10 11:11:00) robinsmidsrod: I don't know a lot about ESI either, but I know it's used a lot in high-performance setups
(2009-07-10 11:11:12) robinsmidsrod: and I'd like to accomodate for it in the design
(2009-07-10 11:11:54) robinsmidsrod: even better link: http://en.wikipedia.org/wiki/Edge_Side_Includes
(2009-07-10 11:14:25) zby: OK - thanks - I'll read about it
(2009-07-10 11:14:45) zby: but to give you some perspective on what I work now on
(2009-07-10 11:14:58) zby: I have in mind a Catalyst::Elements project
(2009-07-10 11:15:11) zby: for assembling basic features to a Cat application
(2009-07-10 11:15:17) zby: like authentication
(2009-07-10 11:15:20) zby: comments
(2009-07-10 11:15:23) zby: etc
(2009-07-10 11:15:31) zby: CRUD
(2009-07-10 11:15:53) zby: I think this is now my priority
(2009-07-10 11:16:22) zby: but I can take part in the discussions about the cms
(2009-07-10 11:16:44) zby: and if you have any particular needs - then I can try to write some Element for it
(2009-07-10 11:16:53) zby: what do you think about that?
(2009-07-10 11:17:03) robinsmidsrod: let me think before I answer
(2009-07-10 11:17:12) zby: yeah - sure
(2009-07-10 11:18:03) robinsmidsrod: your concept seems smart too, the concept being to assemble catalyst components like legos into forming a complete cat-app
(2009-07-10 11:18:32) zby: yes - this is actually quite obvious one
(2009-07-10 11:18:53) zby: what I add to it is that I am trying to make it simple and replaceable
(2009-07-10 11:18:54) robinsmidsrod: it's not so far from what I have in mind - 
(2009-07-10 11:18:58) zby: scaffolding
(2009-07-10 11:19:14) zby: yeah - I hope so :)
(2009-07-10 11:19:45) robinsmidsrod: but I guess I'm more focused on getting the foundation right so that caching and expiry and plugins work with very little effort
(2009-07-10 11:20:18) robinsmidsrod: actually, I somewhat see this as a refinement to what I do at work, but more generic - see portfolio.no
(2009-07-10 11:20:52) robinsmidsrod: that is a project focused on the needs of learning
(2009-07-10 11:21:02) robinsmidsrod: web-based learning
(2009-07-10 11:21:27) zby: interesting
(2009-07-10 11:21:28) robinsmidsrod: so I'm trying to take what knowledge I have from that project and generalize it into 
(2009-07-10 11:21:37) robinsmidsrod: I've been working on that thing since 2005
(2009-07-10 11:21:59) robinsmidsrod: at that time catalyst was just in its infancy (at least from my perspective) so it's not based on catalyst
(2009-07-10 11:22:30) zby: yeah catalyst started in 2005
(2009-07-10 11:23:22) robinsmidsrod: so you can probably understand where the ideas I've written down come from
(2009-07-10 11:23:43) robinsmidsrod: it's sort of a refinement of the stuff I've been doing at work for the last 4 years
(2009-07-10 11:23:52) zby: great!
(2009-07-10 11:24:20) zby: OK - so let me read about the ESI
(2009-07-10 11:24:46) zby: and think a bit how could you fit my Elements idea into your project
(2009-07-10 11:26:21) robinsmidsrod: the very simple concept is that building a website should be like constructing it from lego bricks
(2009-07-10 11:26:54) robinsmidsrod: that's how I thought of the term "block"
(2009-07-10 11:30:07) zby: :)
(2009-07-10 11:32:45) robinsmidsrod: we also need to think about versioning and deprecation of features, and APIs, to make sure that upgrading and such is also clean
(2009-07-10 11:34:00) robinsmidsrod: I was thinking that the blocks themselves could be version, something like what git does with blobs
(2009-07-10 11:34:11) robinsmidsrod: s/version/versioned/
(2009-07-10 11:34:26) robinsmidsrod: this could also enable wiki-like sites that allow rollback of content and history
(2009-07-10 11:35:02) robinsmidsrod: and then maybe a system to purge unreferenced blocks or something
(2009-07-10 11:35:48) robinsmidsrod: as you can see, I have lots of thoughts on the subject - but I'm trying to take a minimalist approach to what the core system should handle
(2009-07-10 11:36:37) robinsmidsrod: I don't know if it's approriate, but think of it somewhat like git for web-development with dynamic content (generated from perl code) thrown into the mix
(2009-07-10 11:37:02) robinsmidsrod: maybe even some code signing for authenticated plugins/blocks or whatever
(2009-07-10 11:40:26) robinsmidsrod: as a photographer and programmer I think of useful applications as e.g. a blog where I talk about programming - my portfolio of my pictures, my photo-plog (which is mostly pictures) - all of this should be possible to host on one installation of the system
(2009-07-10 11:40:46) robinsmidsrod: but I'm also thinking that it could be useful as a ISP hosting solution aswell
(2009-07-10 11:41:38) robinsmidsrod: so a strong API for manipulating the data structures via REST/SOAP or something sounds about right
(2009-07-10 11:42:05) robinsmidsrod: this way you could make tools like the flickr uploader that would allow you to keep your portfolio site updated offline
(2009-07-10 11:42:35) robinsmidsrod: or you could keep a staging system at one location and just sync it to production when you're ready
(2009-07-10 11:42:45) ***robinsmidsrod is just throwing out ideas
(2009-07-10 11:44:47) zby: :)
(2009-07-10 11:44:54) zby: thats a long list
(2009-07-10 11:52:20) robinsmidsrod: yeah - it is
(2009-07-10 11:52:28) ***robinsmidsrod is eating - be back soon
(2009-07-10 13:14:26) robinsmidsrod: okay, I'll be off to do some personal errands, but if you have anything to share about the project please send a pull request for the docs, give me a patch or just shout of some ideas here - I'll eventually be back and will read them
(2009-07-10 13:14:30) robinsmidsrod: c u
(2009-07-10 13:14:53) robinsmidsrod: if Theory comes online, try to invite him here...
(2009-07-10 13:15:13) robinsmidsrod!~robin@197.84-49-220.nextgentel.com: robinsmidsrod has changed the topic to: http://github.com/robinsmidsrod/unnamed-perl-cms-project
(2009-07-10 13:15:45) robinsmidsrod!~robin@197.84-49-220.nextgentel.com: robinsmidsrod has changed the topic to: http://github.com/robinsmidsrod/unnamed-perl-cms-project - have a look at the readme and give me your input
(2009-07-10 18:39:26) Theory [~Theory@c-76-105-135-51.hsd1.or.comcast.net] entered the room.
(2009-07-10 18:40:12) robinsmidsrod: I had a discussion with zby earlier today
(2009-07-10 18:41:08) robinsmidsrod: Theory: I'm not sure how this aligns with your concept - and btw - why are you interested in this when you obviously are deeply involved in bricolage? is it not doing what you want?
(2009-07-10 18:43:28) Theory: Bricolage is a back-end workflow and publishing system.
(2009-07-10 18:43:32) Theory: It doesn't actually serve sites.
(2009-07-10 18:43:46) Theory: Working on a project now where $client develops content in Bricolage and publishes it to a Drupal server.
(2009-07-10 18:43:52) Theory: Drupal has filled me with hate.
(2009-07-10 18:43:56) Theory: QED
(2009-07-10 18:44:48) robinsmidsrod: okay - I have some logs from my conversation with zby, so that you have a bit more meat on the bone in addition to the README
(2009-07-10 18:44:58) robinsmidsrod: btw, please clone that repo and add your bits
(2009-07-10 18:45:44) Theory: will do
(2009-07-10 18:46:23) robinsmidsrod: http://gist.github.com/144612 - here is the log from earlier today
(2009-07-10 18:46:42) robinsmidsrod: hopefully it will sort of highlight what I'm trying to do, in addition to the readme
(2009-07-10 18:48:00) robinsmidsrod: actually, if that is what bricolage is good at, it seems quite obvious that it would be able to plug into this CMS system via its (intended) API
(2009-07-10 18:48:16) Theory: exactly
(2009-07-10 18:48:40) robinsmidsrod: I already have plans for making something like the flickr uploader
(2009-07-10 18:48:56) robinsmidsrod: just for Lightroom :)
(2009-07-10 18:49:33) robinsmidsrod: imagine being able to publish and keep up to date my portfolio photography website directly from my photo manager
(2009-07-10 18:49:37) robinsmidsrod: neat idea
(2009-07-10 18:49:54) Theory: yep
(2009-07-10 18:50:00) Theory: The API is key.
(2009-07-10 18:50:06) Theory: I want a desktop app for managing content.
(2009-07-10 18:50:22) robinsmidsrod: exactly, but before we can make an API we need to know exactly what that API should manage :)
(2009-07-10 18:50:34) Theory: Sure.
(2009-07-10 18:50:40) robinsmidsrod: that is, the data structure and how it all fits together
(2009-07-10 18:50:43) Theory: It should have a blogging API compatible layer, I'll say that much.
(2009-07-10 18:50:59) Theory: Okay, I gotta hack now, but I'll add more later.
(2009-07-10 18:51:08) robinsmidsrod: I see no reason why we cannot make a plugin that wraps that api into our native api
(2009-07-10 18:51:15) Theory: right
(2009-07-10 18:51:58) robinsmidsrod: but what is really important for me is that we really do deployment and upgrading _right_
(2009-07-10 18:52:07) Theory: Yeah, agreed
(2009-07-10 18:52:16) Theory: I was thinking of a shipwright-built installer or something
(2009-07-10 18:52:16) robinsmidsrod: something ala all the php web installers
(2009-07-10 18:52:23) Theory: So users can just unpack it and go
(2009-07-10 18:52:25) Theory: rght
(2009-07-10 18:52:29) Theory: GMTA
(2009-07-10 18:52:30) robinsmidsrod: something you just upload to their webhost and go 
(2009-07-10 18:53:18) robinsmidsrod: if we need extra stuff we sort of bootstrap a local::lib environment (or something else) that will enable us to package cpan modules we need without worries - maybe build it on top of PAR ?
(2009-07-10 18:53:48) robinsmidsrod: we'll probably trip over  some bugs doing that, but in the end it will probably benefit the perl community a lot
(2009-07-10 18:54:02) Theory: Yeah, not sure about PAR
(2009-07-10 18:55:28) robinsmidsrod: its important that we stick with this deployment practice not just for the core, but for plugins aswell, to build a good consensus on how to do things The Right Way
(2009-07-10 18:56:19) Theory: agreed
(2009-07-10 18:56:26) robinsmidsrod: if we really want compatability I think we need to assume that we cannot distribute stuff in source - we need to distribute compiled packages for the platforms
(2009-07-10 18:56:38) Theory: my thought exactly
(2009-07-10 18:56:59) robinsmidsrod: and hopefully set up some kind of repo where people can distribute their plugins/themes/packages/whatever
(2009-07-10 18:57:06) robinsmidsrod: not to riddle CPAN with more than the core
(2009-07-10 18:58:24) robinsmidsrod: so if you're a perl hacker you should be able to just say cpan> install NameOfCMS and off you go - everything taken care of, maybe some questions asked on where you want your root folder to be and such - but it's really just an easy way to download the core distribution
(2009-07-10 18:59:35) robinsmidsrod: or maybe that packages should be the DEV environment, where you actually make plugins
(2009-07-10 19:00:23) robinsmidsrod: as you can see, I have a lot of ideas on how to structure things
(2009-07-10 19:03:37) robinsmidsrod: I'm not exactly sure if I'd like to support windows, so I'd like to limit myself to maybe Debian, Ubuntu, RedHat, Suse, and possibly (Open)Solaris and possibly some of the BSDs for binary support
(2009-07-10 19:03:55) robinsmidsrod: in fact, I'd actually feel comfortable limiting the binaries to platforms that are actually open
(2009-07-10 19:04:16) robinsmidsrod: because then we could just use virtual machines to build the binaries
(2009-07-10 19:04:47) robinsmidsrod: that would actually mean that redhat is out, fedora is in, and suse is out, but opensuse is in
(2009-07-10 19:05:36) robinsmidsrod: if we make the build process painless we should be able to support quite a number of platforms
(2009-07-10 19:06:08) robinsmidsrod: I would also suggest to use exact versions of CPAN modules, to avoid API differences in new modules
(2009-07-10 19:06:45) robinsmidsrod: and manually upgrading to new modules as they pass (our) testing
(2009-07-10 19:07:10) robinsmidsrod: it's a big project - but if we do it right I think people could start to look differently at perl again
(2009-07-10 19:07:19) robinsmidsrod: it's definitely a high profile target