RFC: Replace SS_HTTPResponse/SS_HTTPRequest with HTTPFoundation

68 views
Skip to first unread message

Simon Erkelens

unread,
May 25, 2016, 2:38:24 AM5/25/16
to SilverStripe Core Development
This is a way bigger one.
After talking with Dan a bit this morning, he came up with removing the SS HTTP handlers and replace them with HTTPFoundation.

This is quite a bigger replacement than mailer, Oembed etc., but we're keen for your thoughts.

Sam Minnée

unread,
May 25, 2016, 2:55:41 AM5/25/16
to SilverStripe Core Development
If we replace it with anything it should be something PSR-7 based.

It's generally a good idea, but kind of massive, and I wonder if "make SS_HTTPResponse/SS_HTTPRequest comply with PSR-7" would be an easier first step, to be honest.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
Sam Minnée
CEO
SilverStripe Limited

Simon Erkelens

unread,
May 25, 2016, 3:19:23 AM5/25/16
to SilverStripe Core Development
I have not looked into this. I'd love to hear Dan's reasoning about this, since he actually raised it to me on Slack.

Christopher Pitt

unread,
May 25, 2016, 10:39:31 AM5/25/16
to SilverStripe Core Development

Michael Strong

unread,
May 25, 2016, 5:27:28 PM5/25/16
to silverst...@googlegroups.com
+1 on PSR-7

On 26 May 2016 at 02:39, Christopher Pitt <cgp...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.



--
Michael Strong | Developer
SilverStripe
http://silverstripe.com/

Phone: +64 4 978 7330
Skype: micmania1

Hamish Friedlander

unread,
May 25, 2016, 6:04:36 PM5/25/16
to silverst...@googlegroups.com
I had a quick look at doing this a few hack days ago.  Long story short, I didn't get very far in the few hours I had.

The biggest issue was SilverStripe's bootstrapping. SilverStripe bootstraps by setting up some codebase introspection and then doing magic class discovery, whereas Symfony is more explicitly configured.  There were a few candidates, but no single obvious place to kick off SilverStripe's bootstrapping. This is probably the biggest low-level difference between SilverStripe and other frameworks, and causes difficultly using external components, but it's also something I personally value.

I think there was also a non-trivial dependancy chain, and for a lot of the dependancies duplicated it'd be nice to replace the SilverStripe components with Symfony ones too. I ended up doing lots of yak shaving as a result.

So +1 from me, but don't underestimate the work involved :).

On a meta note: I'm finding it confusing to be using RFC for kicking off discussions. We currently use RFC to mean "a completed suggestion for a core change" (there's lots of detail at https://docs.silverstripe.org/en/3.3/contributing/request_for_comment/). We might need a different tag for "here's a thing I'm thinking about working on that might lead up to an RFC"?

Hamish Friedlander
SilverStripe

Christopher Pitt

unread,
May 25, 2016, 9:45:49 PM5/25/16
to SilverStripe Core Development
Let's add it to the yaklog!
Message has been deleted

Simon Erkelens

unread,
May 25, 2016, 11:10:09 PM5/25/16
to SilverStripe Core Development
Either RFC or RFF should be suitable, but a bit a closer definition of both would be good.

Mark Muller

unread,
May 26, 2016, 11:04:36 AM5/26/16
to SilverStripe Core Development
 
it'd be nice to replace the SilverStripe components with Symfony ones too. I ended up doing lots of yak shaving as a result.

How much 'Silverstripe' will be left after all the core modules have been replaced with 'XX' frameworks modules? Should I just start looking at using 'XX' framework for future projects is starting to go around my mind a bit to be honest with all these changes being proposed...

Just at thought!

Mark
 

Christopher Pitt

unread,
May 26, 2016, 11:59:27 AM5/26/16
to SilverStripe Core Development
Mark,

This is not unlike what Laravel does. There is a relatively tiny amount of code Taylor actually writes, on top of the Symfony (and other community) libraries. Yet it is still the most popular PHP framework out there. People like Laravel (arguably) because it creates simple interfaces to commonly used code. It's just (arguably) nicer to use than creating the equivalent applications using only Symfony components.

The importance of open source frameworks (and CMS's) is what they bring to the table. What is the value of WordPress or Magento or Drupal or SilverStripe? What do each do differently that makes them attractive for certain applications and unattractive for others? 

We could remove 90% of the SilverStripe codebase and still keep the rich custom page type functionality, the same CMS scaffolding, the same template engine. Those are some of the things that make SilverStripe unique, and they are not dependant on who is bringing the router or the filesystem drivers to the table.

Loz Calver

unread,
May 26, 2016, 12:02:47 PM5/26/16
to SilverStripe Core Development
I think that’s a valid concern to have. None of us want to detract from the core “SilverStripe experience” by essentially becoming another framework (or collection of frameworks). These sorts of RFCs are mostly about reducing the amount of code we have to maintain that sits “behind the scenes”, and making use of other frameworks/packages that quite simply do things better than we do.

For some of these RFCs, “user code” would likely be unaffected - e.g. replacing our core Mailer implementation with SwiftMailer wouldn’t drastically change how people use Email::create($stuff)->send();. This particular RFC may require some changes to how controllers work, which would potentially affect user code (I don’t know how much as I’m not overly familiar with PSR-7), but I don’t think that’s necessarily a bad thing in this case: if developers already using other frameworks that are PSR-7 compliant want to try out/switch to SilverStripe, then that’s one less thing they need to re-learn.

The reality is that stuff moves pretty quickly in the land of software development, and we (as a community of contributors) don’t always have enough time or the inclination to maintain and improve everything that’s in framework. There are many classes (Mailer being one of them) that have barely been touched since the 2.4 days. Sure, we could spend a lot of effort improving them, but why bother when there are more actively maintained, better tested packages out there?

If it helps put your mind at rest:
  • Not all these RFCs will happen. As Hamish pointed out above, the RFC tag is probably the wrong thing to be using for “I’ve had an idea, this might be nice”. I’ve probably mis-used this with the RFC I wrote too, so I’m not finger pointing here :)
  • We (the core team) vote to accept/reject RFCs, and we’re not going to be voting in any huge changes without consideration for backwards compatibility, developer experience etc
Loz

Patrick Nelson

unread,
May 26, 2016, 1:53:30 PM5/26/16
to silverst...@googlegroups.com
To be fair Mark, SilverStripe does a LOT that many other systems don't do. What SilverStripe should not be doing is reinventing the wheel. I'm fully in agreement with Loz. What we need to do is focus on what value SS provides and outsource/abstract away that which we use to accomplish those goals unless, of course, that isn't possible. Then, we should invent something (new) and maybe push tech forward a bit :)

Speaking of: This HTTP stack. I've had troubles with it in the past and I think more standardized and feature-rich frameworks might do a much better job at handling some of the more fundamental issues which simply occur when you go out and "roll your own" (e.g. tight bindings, global state, etc).

TL;DR: I'm 100% on board with this sort of transition!

Sam Minnée

unread,
May 26, 2016, 7:34:46 PM5/26/16
to silverst...@googlegroups.com
The most important thing is that, with all these changes, we don't make it a whole lot harder for people to "just use SilverStripe". This comes down to how these changes are approached more than whether we do them.

Regarding HTTPRequest/Response, I'm much more interested in making the rest of SilverStripe work with any PSR-7 compatible implementation than am I with swapping one specific library with another specific library.

One way to start this would be to extend our current classes or add a wrapper to them so that they are PSR-7 complaint, to deprecated the non-PSR-7 accessors, and then to rewrite all the code that depends on HTTPRequest/Response to use the PSR-7 accessors.

If that is done, then shifting to another PSR-7 implementation in the future (or to do so on a different project) should be a lot more straightforward.

The other thing I would say is that developers should be able to mix and match different libraries, components, and capabilities of SilverStripe.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
Reply all
Reply to author
Forward
0 new messages