How do you plan to use the library?

[tgalopin]

Hello everyone,

I know most of the use cases of this library will be quite classical: conversation between users. However, some of you may have ideas of what they need that we didn't think of.

Please don't hesitate to propose ideas about this library, about how you would like it to work.

[dbu]

i think its a good idea to formulate a mission statement and also be strict about it in the sense that you reject features that try to make the library do something completely different than the mission statement. it should be focussed on some tasks. if you end up doing all imaginable kind of messaging, it can become hard to maintain and very hard to get into as a new user of the library. the more flexibility, the more complexity and the steeper learning curve. if there is some small detail that gives a lot of flexibility for third party code to do other things than intended, that makes sense. but adding whole new layers of functionality is probably not.

[tgalopin]

I completely agree, we have to keep the library clear about what it does: simple messaging between users.

On the other hand, I reviewed the issues of the bundle and some ideas were interesting while staying in the scope of the library. For instance, the tagging system is a generic and simple way to provide several features (directories, search, conversations status, etc.) and it does fit in the library.

[ionafan2]

Hi @tgalopin just don't forget this statement "...simple messaging between users." after 1k commits ;)
And about other hand - provide file attachment ability in core objects (not full functionality implementation, just possibility to implement it in your own project if you will need it).

[ionafan2]

One more thing I think we should keep in mind: often the SocialNetwork (or Friends) functionality is the reason when the project need the messaging system. So there have to be smart validation layer where developers can put theirs validators such as "isFriend, "isBlocked" etc.

[stof]

@ionafan2 I don't think we need anything special about the validation. People would just register additional constraint for the Symfony validator for the classes (assuming we rely on the Symfony validator). this way, they can add whatever validation rule they want without any change in the library.

@tgalopin regarding tagging, the question is whether this needs to be in the library, or whether the library should just have enough extension points to allow having it built on top of it. In some cases, it is more maintainable to provide an extension point than to build the feature directly (and the extension point can be used to build several features generally)

[ionafan2]

@stof yes, you are right. I'm just notice you that the way when adding new behavior is better than extending or changing existing in example on validations, it can be filters or something else

[tgalopin]

For the validation I think @stof is right, adding validation rules is just adding custom methods in the models child classes. We don't want to take care of validation in the library.

I'm not totally sure right now if the tagging system should be in the core library or not. A dilemma I have is how to deal with read/not read conversations status. As discussed in FriendsOfSymfony/FOSMessageBundle#112, I think we should store this state in the entity linking a conversation and a user (ConversationPerson) and not on the messages (like in the bundle). I think tagging could be a way to store this status.

On the other hand, we probably want more precision than just a tag, like what is the last message seen (or better, what is the last visit date, to avoid a link to a message). Storing the last visit date let the developer redirect the user to the right page in the conversation if the conversation is paginated for instance.

In the end, I think the best would be to have in the ConversationPerson object a field $lastSeenDate, the repository could have a method to retrieve the last message seen by a given person in a given conversation and the tagging system could be externalized (something optionnal) as @stof proposed. I'm thinking of something like:

$conversation = $repository->getConversation($id);
$lastMessageSeen =  $repository->getLastMessageSeen($conversation, $person);

// We can find the right page to redirect the user to if we paginate conversations

What do you think of this?

[tgalopin]

I started an issue for the missions of the library to summarize the different discussions we had in the different topics: #5.

If you could give your input, that would be great!