What is the mission of this library ?

[tgalopin]

While we probably all agree that this library aims to provide user-to-user messaging features, I'm not sure we all have the same idea of what we should really do.

I discussed quite a lot with @ChristianRiesen about this and we worked on an easy to use API for the library. I want to explain here what is our current idea so it can be discussed and adapted to your needs.

1. We don't base the work on the current bundle

We chose to not base our work on the bundle. We didn't want to be restricted in our ideas by the bundle concepts. So even if some ideas will be the same, please keep in mind we want to create a library from scratch.

2. The library and framework implementations

• FOSMessage is conversation-based and supports multiple participants per conversation.
• FOSMessage is divided in two parts: the library and its implementation in frameworks (bundle, module, etc.).
• The library is very simple: it's nothing more than a coherent data structure. We don't provide validation, UI, forms, etc. The developer will use the library as a way to persist and fetch messages in an elegant way.
• The framework implementation of the library (bundle, module, etc.) may implement more things to help the development.
• The library won't implement any "inbox/sentbox" system as it's quite complex to define what a sent message is. The framework implementation may implement it in the context of the UI.
• The library is independant from any framework, any persistance system and any user system.

3. Implementation details

• The library provides two main components:
  • The Repository to fetch conversations / messages
  • The Sender to start conversations / send messages
• The library provides other components (for the moment only one) that can be used but are optionnal (they will have a seperated documentation page):
  • The Tagger to tag conversations
• The library provides a few models: Conversation, Message, PersonInterface (interface for User model), ConversationPerson linking conversations and persons and MessagePerson linking messages and persons ;
• A TagInterface let the developer implement a tagging system ;
• Drivers let the developpers choose what persistance system they want to use (we decided in What persistance systems do we have to support for first release? #1 to limit the persistance systems to Doctrine ORM and Mongo ODM)
• An event dispatcher is available (either a native one to use the library alone or various bridges with famous event dispatchers, for the moment, only Symfony: https://github.com/tgalopin/message/tree/master/src/EventDispatcher)

4. Usage ideas

Here is how we would like to interact with the library, as a developer: https://gist.github.com/tgalopin/33641d43f200e8010c2a

You can note that there is neither any concept of inbox/outbot nor validation or UI. The library as we plan it is a smart but simple data strcture, and nothing more.

I worked a bit on an implementation of what we had in mind with Christian (https://github.com/tgalopin/message) so the code can help you see how the library would work from our perspective.

I am very interested by your opinions about this plan: what do you think the library should be? What was your idea when you thought of a framework-agnostic messaging library? Does this plan fit your needs?

[Alexandre-T]

For an end-user application. I use the earlier FOSMessageBundle version. I had a look of this new project and read this interesting post. I like very much the choosen orientation, implement any inbox/sentbox system as it's quite complex. The TagInterface is a better way to order and filter messages. The frontend developper don't have to implement new features to realise some virtual box. He can easily create a visual "general inbox", "forum inbox", "social network inbox" like Gmail if users are asking boxes. To do it, he only have to override your template.

You're interested by our opinion and new use cases. I think that export and batched operations (mass deleting, mass tagging) are features waited by users.

An AJAX API will be usefull to retrieve some thread content or filtered thread list.

Sorry for my english, I am not fluent. I hope I have made this sufficiently clear and I have been of some help to you.

[tgalopin]

@Alexandre-T Thanks very much for your opinion, that's indeed very important to me :) . And your english is great, don't worry :) .

Your proposals are interesting. We should definitely provide a way to access raw data (without using the Repository) in order to be able to manipulate a lot of conversations / messages at the same time, without having the Repository constraints, that's a good point.

For the API, that's something that could be really useful, especially to use the bundle as a micro-service. However, it will be something implemented by the bundle, not by the library. But I keep it in mind :) .

[Alexandre-T]

I did not understand that there was a librairy on one side and the bundle of other one. I thought that this project was the 1.2 version. I was surprised by this sentence : "The library is independant from any framework.". Now, I know better.

I would really like to spend a bit of time on this library and the bundle. But it is impossible for me before mid-november. On github, I have flagged library and bundle repository. I note both on my schedule and I come back to you if I have availability.

[iBasit]

Via event dispatcher or maybe as feature to read / write messages via email (directly from email box)

[tgalopin]

In a project I have in mind, I'm thinking of this too. You should be able to use the library with e-mails as a backend in the idea I developed in the first post. I will try to implement it in reality to see if I have problems.

[dbu]

emails seem a typical case that should be easy to implement, but not something built into the library i think.

[tgalopin]

I totally agree, that's exactly what I had in mind. Perhaps just a
documentation page.

Le ven. 9 oct. 2015 15:09, David Buchmann [email protected] a
écrit :

emails seem a typical case that should be easy to implement, but not
something built into the library i think.

—
Reply to this email directly or view it on GitHub
#5 (comment)
.

[iBasit]

Documentation page would be perfect. and also instant notification (pub/sub) documentation with the messaging would be nice. These are basic features now days.

[tgalopin]

I started the documentation here: http://fosmessage.readthedocs.org.

[soerenmartius]

Hi @tgalopin why did you even provide an implementation of a doctrine driver within this library? Isn't that an implementation specific part? I think a library ( and you describe it as a library ) shouldn't deal with the persistence at all, this should then go in the bundle which is implementing this library.

[dbu]

on the other hand, there is no hurt in having a persistence implementation for a widely used storage system. you are free to ignore its existence and have your own persistence implementation.

[tgalopin]

That's something we can argue about in the case of "important" architectural and support decisions (if supporting a library requires architecture changes, that's bad). Here, we are simply providing a useful tool for the most used persistance tool in the PHP world.

[soerenmartius]

I don't really agree with your opinion. Having dependencies to doctrine ( collection ) in your plain model files is an unneeded dependency for user who might not use doctrine at all. I would overwrite the specific methods in the doctrine implementation then ( in your case the entites ).

Also, in the current approach you are annotating your class, a better way would be to do the mapping via yml or xml for ORM and ODM, so you don't duplicate code. Just my 5 cents :)

Don't get me wrong, this library is brilliant i do like it, i just think it might be cleaner to put the persistence specific stuff the implementation of the library.

[tgalopin]

Having dependencies to doctrine ( collection ) in your plain model files is an unneeded dependency for user who might not use doctrine at all.

doctrine/collections is a tiny library. The library also uses Composer: what about people not using Composer? Should I provide a way to install the library without it?

Also, in the current approach you are annotating your class, a better way would be to do the mapping via yml or xml for ORM and ODM, so you don't duplicate code. Just my 5 cents :)

This point could be debated, but I chose annotations as I think it's clearer.

Don't get me wrong, this library is brilliant i do like it, i just think it might be cleaner to put the persistence specific stuff the implementation of the library.

Thanks, I'm glad you like it :) . If you want to open a PR for yml/xml mapping, I'd merge it gladly :) .

[soerenmartius]

Having dependencies to doctrine ( collection ) in your plain model files is an unneeded dependency for user who might not use doctrine at all.
doctrine/collections is a tiny library. The library also uses Composer: what about people not using Composer? Should I provide a way to install the library without it?

haha come in, don't blame me for this one 🎱

[dbu]

+1 for xml entity mappings in libraries. having to copy properties just so we can annotate them is awkward. annotations imho are good for entities in custom projects, but less so in reusable libraries.