[Solar-talk] Change to Solar system assumptions?

[Dmytro Konstantinov]

Paul,

Personally I 100% agree with you! In my experience, most of us end up  
setting up, at the very least, 2 completely self contained trees for  
each project: one to keep the development/cutting edge code in, the  
other one is to keep the stable code in. I haven't encountered any  
problems with keeping Solar local to a single-project tree, but as  
you've said, there is room for improvement in that direction!

Looking forward to seeing what you have in mind! :)

Dmytro


On 17 May 2008, at 16:47, Paul M Jones wrote:

> Hi everyone,
>
> Since its beginning, Solar development has been very much an  
> extension of how PEAR does things.  PEAR assumes that there is one  
> one shared library for all applications and projects; sometimes the  
> shared library is for the entire server, sometimes it is for all the  
> projects for one user on a server, but "shared everything" has been  
> the foundational assumption.  Even if you have multiple projects,  
> PEAR expects they will all use a common library set.
>
> The Ruby on Rails crowd, and their imitators in the Symfony and Cake  
> projects, have a different approach.  With them, you have one self- 
> contained project system, and no references to anything outside that  
> system.  If you have multiple projects, you have multiple separate  
> library collections for them.  This means that core libraries are  
> usually duplicated across projects.
>
> Over the past few weeks, I come to believe that the Rails (et al)  
> approach is the more effective solution for web application  
> projects.  I think that Solar, while still maintaining itself as a  
> PEAR-library-style framework, should start assuming that it will be  
> part of a project-specific system, not a server-wide system.
>
> There are a few implications of this change in approach:
>
> * The PEAR-style distribution of Solar as a library set should not  
> change; you should still be able to `pear upgrade Solar` for PEAR  
> compatibility.
>
> * There should be a *second* distribution mechanism: a downloadable  
> "project directory" with the full project structure already in  
> place, Solar in the "source" and "include" directories, the  
> bootstrap file in the "docroot" directory, and so on.  This will  
> make first-time setups much easier.
>
> * The binary `solar` CLI tool should *not* look through the server  
> in various places for its config files.  Instead, it should look in  
> the project "config" directory.  (You can still specify an alternate  
> config file with --config.)  (The same would be true for the  
> bootstrap file -- it should look in the "config" directory.)
>
> Those are all the changes I can think of that would apply with the  
> "project-specific" assumptions (rather than "system-wide"  
> assumptions).
>
> I'd like to hear any and all criticism of this proposed change to  
> the Solar assumptions.  I think we're all doing our projects this  
> way, but I want to make sure I'm not missing anything.
>
>
> -- pmj
> _______________________________________________
> Solar-talk mailing list
> Solar-talk at lists.solarphp.com
> http://mailman-mail3.webfaction.com/listinfo/solar-talk