Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Branding cross-framework modules #3

Open
moufmouf opened this issue Nov 25, 2015 · 5 comments
Open

Branding cross-framework modules #3

moufmouf opened this issue Nov 25, 2015 · 5 comments

Comments

@moufmouf
Copy link
Contributor

The README states that definition-interop tries to offer a solution for writing cross-framework modules.

But actually, definition-interop is really one piece of a big puzzle that leads to cross-framework modules.
In order to have cross-framework modules we need:

  • one or many "loaders" to convert YML / JSON / whatever files to definition objects
  • one or many implementations of the definition-interface (mnapoli/assembly)
  • a mechanism to discover those files (Puli)
  • a mechanism to discover the available loaders (maybe Puli)
  • one or many implementations of a container consuming definitions (thecodingmachine/yaco, PHP-DI soon?)
  • a Symfony bundle to directly convert definition-interop object to Symfony definitions
  • for each framework, either a direct support of definition-interop objects or a PSR-11 compliant container that can be linked to a container that is both PSR-11 compliant and definition-interface compliant (Yaco, maybe PHP-DI soon?)

So basically, the global solution is wider than the scope of definition-interop, that should probably only focus on definitions interoperability.

I'm wondering if at some point (not necessarily now), we should not think about branding this whole cross-framework modules idea under some catchy name.

For instance:

  • Harmony packages
  • or Universal packages

(I like the "harmony" name because it conveys the idea of frameworks/modules working together in harmony, and just like symfony and composer, it is music related)

We could build a simple Couscous website explaining the concept and how it applies to every kind of developers out there.

The website could have those sections:

  • For framework developers
  • For package developers
  • For end-application developers

Also, the website could make a number of recommendations about services naming to avoid conflicts, etc...

What do you people think? Is "branding" this initiative a good idea? Is it too early?
If you think this is a good idea, I'm willing to work on a first version.

@mnapoli
Copy link
Member

mnapoli commented Nov 25, 2015

It's a good idea! But I think it's too early, we have to try the idea first and assert it solves the problem we want to solve.

@mnapoli
Copy link
Member

mnapoli commented Nov 26, 2015

Just coming back on this, when I said "it's too early" I meant not wait months but maybe only days or weeks. It's just that before trying to attract too much attention on the project I'd rather have something we are sure that works.

And except that, I agree with everything you suggested.

@moufmouf
Copy link
Contributor Author

👍
By the way, shall we start gathering some feedback from PPI or ZF3?
I promised Paul Dragoonis I would make a summary of what we said on the PHP-FIG mailing list. We should do it at some point, but this might be a bit early. What do you think?

@mnapoli
Copy link
Member

mnapoli commented Nov 27, 2015

Yes we definitely should. For the summary to the FIG maybe we could wait for their answer first in case they see some major issue that we missed (hopefully not)? And after that it would be good to update the FIG indeed.

@moufmouf
Copy link
Contributor Author

I wrote a blog article explaining the idea behind "Harmony" packages. I'm putting a link to the article here, for the record: http://www.thecodingmachine.com/interoperable-php-packages-with-definition-interop-and-puli/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants