Hello all,
I wish I would say I would have something new to say....but I am pretty much in the same position I was in last time I posted. I got some help on trying to hunt down who to contact for upstream patches of mmsd, and from the sounds of it, I more or less have to wait for Bullseye to come out before anything will happen for my debian packaging. I packaged up upstream mmsd in the hopes that will be easier to get into packaging as well.
Chatty still has a higher priority issue they are working on as well.
Chatty dev's don't accept merge request ? Or is your implementation more subtle than just merging code to their base ?
Anyway, I totally understand about Bullseye. It's a pitty but understandable...
Keep up the good work and thank you for all your efforts ! I support you 100% on this (for what it's worth  ).
03-25-2021, 07:19 PM
(This post was last modified: 03-25-2021, 07:21 PM by kop316.)
(03-25-2021, 07:11 PM)bitsandnumbers Wrote: Chatty dev's don't accept merge request ? Or is your implementation more subtle than just merging code to their base ?
Anyway, I totally understand about Bullseye. It's a pitty but understandable...
Keep up the good work and thank you for all your efforts ! I support you 100% on this (for what it's worth ).
The Chatty Dev has actually been really good to work with! The issue there is is a bit more subtle: Chatty as it stands now depends on libpurple for SMS support. libpurple, to put it nicely, has not aged well at all, and is not very flexible, and the documentation is awful. This forced the chatty devs to basically "absorb" all of the responsibilities of libpruple into chatty.
Much of the backend is there (which is why I was able to write a reference implimentation for MMS into chatty). However, there still is a lot of work to call it "stable". They intend on working on it as soon as they finish the project they are working on now. I get the impression that the devs are not setting the priority, but someone higher within Purism.
And thank you for the kind words. I am admittedly frustrated with the upstream process on mmsd (Ofono folks apperently don't accept MRs or respond to emails for mmsd), and I would have hoped the Debian packaging efforts would have gone faster. I guess all I can really do is wait......
So while I am waiting for other things, I have been debating what makes sense as "next steps" for development. However, when you are a person of one, it's easy to just stay inside your head and not go anywhere. I say that to say there is a lot of traffic to this thread, so I was wondering if there are thoughts in logical next steps (besides Chatty integration, packaging, and upstreaming). Right now I have come up with a couple of ideas:
Modem Manager: having mmsd autoprocess SMS WAPs:
https://source.puri.sm/kop316/mmsd/-/issues/6
I think this makes a lot of sense. I originally didn't add this due to the fact that Chatty/purple-mm-sms processes SMS WAPs and hands them off to mmsd. However, I think this allows mmsd to be more autonomous, and makes it easier for higher level applications to build in MMS support.
Modem Manager: having mmsd support SMS:
https://source.puri.sm/kop316/mmsd/-/issues/7
I don't know if I like this idea or not. I can see it being useful, but I also see it as mmsd doing more than MMS (which there is use in keeping it MMS only), and then it becomes a question of should mmsd also support sending SMS too?
For lack of a better option, I'll throw it out there and see if others have different ideas too.
(04-05-2021, 11:53 AM)kop316 Wrote: So while I am waiting for other things, I have been debating what makes sense as "next steps" for development. However, when you are a person of one, it's easy to just stay inside your head and not go anywhere. I say that to say there is a lot of traffic to this thread, so I was wondering if there are thoughts in logical next steps (besides Chatty integration, packaging, and upstreaming). Right now I have come up with a couple of ideas:
Modem Manager: having mmsd autoprocess SMS WAPs:
https://source.puri.sm/kop316/mmsd/-/issues/6
I think this makes a lot of sense. I originally didn't add this due to the fact that Chatty/purple-mm-sms processes SMS WAPs and hands them off to mmsd. However, I think this allows mmsd to be more autonomous, and makes it easier for higher level applications to build in MMS support.
Modem Manager: having mmsd support SMS:
https://source.puri.sm/kop316/mmsd/-/issues/7
I don't know if I like this idea or not. I can see it being useful, but I also see it as mmsd doing more than MMS (which there is use in keeping it MMS only), and then it becomes a question of should mmsd also support sending SMS too?
For lack of a better option, I'll throw it out there and see if others have different ideas too. Would pursuing Issue 6 help with implementing MMS on systems that do not use purple-mm-sms? I read that you are having trouble reaching the ofono developers, would this possibly help/limit the need ofono integration?
04-05-2021, 07:52 PM
(This post was last modified: 04-05-2021, 08:43 PM by kop316.)
(04-05-2021, 07:08 PM)hinton.s.b Wrote: (04-05-2021, 11:53 AM)kop316 Wrote: So while I am waiting for other things, I have been debating what makes sense as "next steps" for development. However, when you are a person of one, it's easy to just stay inside your head and not go anywhere. I say that to say there is a lot of traffic to this thread, so I was wondering if there are thoughts in logical next steps (besides Chatty integration, packaging, and upstreaming). Right now I have come up with a couple of ideas:
Modem Manager: having mmsd autoprocess SMS WAPs:
https://source.puri.sm/kop316/mmsd/-/issues/6
I think this makes a lot of sense. I originally didn't add this due to the fact that Chatty/purple-mm-sms processes SMS WAPs and hands them off to mmsd. However, I think this allows mmsd to be more autonomous, and makes it easier for higher level applications to build in MMS support.
Modem Manager: having mmsd support SMS:
https://source.puri.sm/kop316/mmsd/-/issues/7
I don't know if I like this idea or not. I can see it being useful, but I also see it as mmsd doing more than MMS (which there is use in keeping it MMS only), and then it becomes a question of should mmsd also support sending SMS too?
For lack of a better option, I'll throw it out there and see if others have different ideas too. Would pursuing Issue 6 help with implementing MMS on systems that do not use purple-mm-sms? I read that you are having trouble reaching the ofono developers, would this possibly help/limit the need ofono integration?
> Would pursuing Issue 6 help with implementing MMS on systems that do not use purple-mm-sms?
(NOTE: this only applies to modem manager) Correct. If you do not use purple-mm-sms/chatty, you need to build your own monitor to look for SMS WAPs and then send the SMS WAP to mmsd. If I just add SMS WAP monitoring functionality to mmsd (which adding this functionality is not a lot of work, probably a day or so), than you will not need to worry about monitoring SMS WAPs in a seperate program. I think this makes for a cleaner abstraction for MMS with mmsd.
My original thought was that SMS chat program monitors incoming SMS anyways, so adding the functionality to send SMS WAPs to mmsd is likewise minimal. I also did not want some sort of race condition between an SMS chat program and mmsd (i.e. both see the same SMS WAP and try to do something about it). This was why I left this functionality out of mmsd and only in purple-mm-sms/chatty. However, after working on both sides for a bit, I think I was being too cautious. I think I will end up adding the SMS WAP monitoring functionality into mmsd and add a user option for if it should be active or not.
I was additionally wondering if I do Issue 6, then does it make sense to then bake in SMS functionality as well (Issue 7). I am not convinced I should do that. Right now I am thinking mmsd should only focus on MMS (it is called mmsd afterall), and SMS sending/recieving is much more straight forward with modem manager. But, I figured I should write it down and think about it anyways. If I did add it, it would be a user option as well.
> I read that you are having trouble reaching the ofono developers, would this possibly help/limit the need ofono integration?
Ofono is a seperate plugin in mmsd. While I do not use/test the ofono-plugin, none of my work should cause regressions on it (and if anything, the bugs I have fixed in the core should benefit ofono as well), and the plugin is compiled in by default. If someone has updates to the ofono plugin, I welcome MRs.
(04-05-2021, 07:52 PM)kop316 Wrote: I was additionally wondering if I do Issue 6, then does it make sense to then bake in SMS functionality as well (Issue 7). I am not convinced I should do that. Right now I am thinking mmsd should only focus on MMS (it is called mmsd afterall), and SMS sending/recieving is much more straight forward with modem manager. But, I figured I should write it down and think about it anyways. If I did add it, it would be a user option as well.
Ideally, in my mind, this is how it _should_ work. There should be one "mms-smsd". Every application that wants to send a "message" should go through the one daemon. This way, applications will neither know nor care whether it is an SMS or an MMS. The application just passes the message to mmsd and mmsd figures out how to send it.
Eventually, mmsd will support RCS as well in my fantasies ...
04-06-2021, 10:13 AM
(This post was last modified: 04-06-2021, 10:16 AM by kop316.)
(04-06-2021, 09:30 AM)blendergeek Wrote: (04-05-2021, 07:52 PM)kop316 Wrote: I was additionally wondering if I do Issue 6, then does it make sense to then bake in SMS functionality as well (Issue 7). I am not convinced I should do that. Right now I am thinking mmsd should only focus on MMS (it is called mmsd afterall), and SMS sending/recieving is much more straight forward with modem manager. But, I figured I should write it down and think about it anyways. If I did add it, it would be a user option as well.
Ideally, in my mind, this is how it _should_ work. There should be one "mms-smsd". Every application that wants to send a "message" should go through the one daemon. This way, applications will neither know nor care whether it is an SMS or an MMS. The application just passes the message to mmsd and mmsd figures out how to send it.
Eventually, mmsd will support RCS as well in my fantasies ...
> mmsd will support RCS as well in my fantasies ...
Do you have any knowledge of where to look for a reference on this? It would be interesting to see how RCS works,
https://www.gsma.com/futurenetworks/rcs/ seem to be the ultimate authority on it, with this document specifying clients:
https://www.gsma.com/futurenetworks/wp-c...-v11.0.pdf
but it would be easier to look at reference code. The Google messaging RCS is proprietary as far as I can tell. Also as a note:
"Operators are free to decide whether or not to implement RCS within their 4G networks. However, the 5G standards mandate the implementation of RCS in 5G networks and devices."
https://www.gsma.com/futurenetworks/rcs/...l-profile/
It looks like if one were to impliment 5G, one needs RCS.
04-06-2021, 03:42 PM
(This post was last modified: 04-06-2021, 03:45 PM by bitsandnumbers.)
(04-06-2021, 09:30 AM)blendergeek Wrote: (04-05-2021, 07:52 PM)kop316 Wrote: I was additionally wondering if I do Issue 6, then does it make sense to then bake in SMS functionality as well (Issue 7). I am not convinced I should do that. Right now I am thinking mmsd should only focus on MMS (it is called mmsd afterall), and SMS sending/recieving is much more straight forward with modem manager. But, I figured I should write it down and think about it anyways. If I did add it, it would be a user option as well.
Ideally, in my mind, this is how it _should_ work. There should be one "mms-smsd". Every application that wants to send a "message" should go through the one daemon. This way, applications will neither know nor care whether it is an SMS or an MMS. The application just passes the message to mmsd and mmsd figures out how to send it.
Eventually, mmsd will support RCS as well in my fantasies ...
I don't understand everything about your work here @ kop316 , but as an adept of the KISS principle, I can only adhere to what @ blendergeek is suggesting. One could argue that KISS would be having one daemon doing one thing and doing it good, but MMS/SMS are pretty much the same thing, one being just richer than the other (at least from an end-user POV, also when you use SMS/MMS, you usually use the other), so one daemon managing both does not bother me here. And it would also save nights for future devs wanting to make SMS/MMS clients I assume... I'm not technical on the matter though, so I'm just giving my Linux user opinion.
04-06-2021, 04:22 PM
(This post was last modified: 04-07-2021, 05:44 AM by kop316.)
(04-06-2021, 03:42 PM)bitsandnumbers Wrote: (04-06-2021, 09:30 AM)blendergeek Wrote: (04-05-2021, 07:52 PM)kop316 Wrote: I was additionally wondering if I do Issue 6, then does it make sense to then bake in SMS functionality as well (Issue 7). I am not convinced I should do that. Right now I am thinking mmsd should only focus on MMS (it is called mmsd afterall), and SMS sending/recieving is much more straight forward with modem manager. But, I figured I should write it down and think about it anyways. If I did add it, it would be a user option as well.
Ideally, in my mind, this is how it _should_ work. There should be one "mms-smsd". Every application that wants to send a "message" should go through the one daemon. This way, applications will neither know nor care whether it is an SMS or an MMS. The application just passes the message to mmsd and mmsd figures out how to send it.
Eventually, mmsd will support RCS as well in my fantasies ...
I don't understand everything about your work here @kop316 , but as an adept of the KISS principle, I can only adhere to what @blendergeek is suggesting. One could argue that KISS would be having one daemon doing one thing and doing it good, but MMS/SMS are pretty much the same thing, one being just richer than the other (at least from an end-user POV, also when you use SMS/MMS, you usually use the other), so one daemon managing both does not bother me here. And it would also save nights for future devs wanting to make SMS/MMS clients I assume... I'm not technical on the matter though, so I'm just giving my Linux user opinion.
Hello,
Fair enough, I do appreciate it! I think first on my list is finishing the auto processing of SMS WAPs then looking at what is involved for just general SMSes.
EDIT: while I was looking through the APIs for SMS on modem manager, I actually think that modem manager supports SMS very well, and I don't see anything that mmsd would really add with general SMS support. As such, I think I am just closing that issue.
|
