Going through old issues, I see one [1] regarding adding SCTP [2]
support. I've not heard of this protocol before. What are its benefits and use case for Pharo/Squeak ? Regarding our resource constraints, modularisation goal and ongoing support, what is our strategy for this? 1. Integrate for Pharo 5? 2. Integrate into VM as plugin and have as external Configuration for image? (btw, remind me if a Configuration can also add a VM plugin?) 3. Continue to leave it for later. 4. Decline to use it. Holger, What application are you using this for, and how are you managing to work with this at the moment? [1] https://pharo.fogbugz.com/default.asp?7346 [2] https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol cheers -ben |
> On 05 Aug 2015, at 19:59, Ben Coman <[hidden email]> wrote: Hi, > Going through old issues, I see one [1] regarding adding SCTP [2] > support. I've not heard of this protocol before. What are its > benefits and use case for Pharo/Squeak? SCTP was designed by the telecommunication community to migrate from systems using MTPL2/MTPL3. I am not going into the benefits of SCTP itself but this protocol is the base for “SIGTRAN” and also for backend systems in LTE networks. It was considered for things like WebRTC as well. > Regarding our resource constraints, modularisation goal and ongoing > support, what is our strategy for this? > 1. Integrate for Pharo 5? no > 2. Integrate into VM as plugin and have as external Configuration for > image? (btw, remind me if a Configuration can also add a VM plugin?) no > 3. Continue to leave it for later. I am not sure. I think there should be two separate items: * The SocketPlugin should know the SCTP network type and operations like socket(2)/connect(2)/bind(2) should work. The beauty of the BSD socket design is that the VM only needs to know how to deal with a filedescriptor. * There should be an additional plugin to bind the advanced sctp primitives. This could work on OSX, FreeBSD and Linux. > 4. Decline to use it. Then I have to find different kind of work. :) > Holger, What application are you using this for, and how are you > managing to work with this at the moment? I am using a piece of C application that handles SCTP/SIGTRAN and provides a TCP/IP relay for Pharo. |
On Thu, Aug 6, 2015 at 2:12 AM, Holger Freyther <[hidden email]> wrote:
> >> On 05 Aug 2015, at 19:59, Ben Coman <[hidden email]> wrote: > > Hi, > > >> Going through old issues, I see one [1] regarding adding SCTP [2] >> support. I've not heard of this protocol before. What are its >> benefits and use case for Pharo/Squeak? > > SCTP was designed by the telecommunication community to migrate > from systems using MTPL2/MTPL3. I am not going into the benefits > of SCTP itself but this protocol is the base for “SIGTRAN” and also > for backend systems in LTE networks. It was considered for things like > WebRTC as well. > > >> Regarding our resource constraints, modularisation goal and ongoing >> support, what is our strategy for this? > >> 1. Integrate for Pharo 5? > > no > > >> 2. Integrate into VM as plugin and have as external Configuration for >> image? (btw, remind me if a Configuration can also add a VM plugin?) > > no > > >> 3. Continue to leave it for later? > > I am not sure. I think there should be two separate items: > > * The SocketPlugin should know the SCTP network type and operations > like socket(2)/connect(2)/bind(2) should work. The beauty of the BSD > socket design is that the VM only needs to know how to deal with a > filedescriptor. > > * There should be an additional plugin to bind the advanced sctp primitives. > This could work on OSX, FreeBSD and Linux. > So it seems you only need VM changes integrated. How would you feel about working directly with the vm-dev community to do this? A ticket in the Pharo bugtracker is implicitly waiting for someone else to pick it up and push it, but Pharo has only a few busy people to work on the VM, thus your ticket there has languished >2yrs. There are more non-Pharo vm-devs (who don't follow the Pharo bug tracker), so going direct you might have a broader chance of getting it reviewed and integrated. This might not have been so practical when you first logged your ticket since at that time the Pharo-VM had diverged from the mainline-Cog-VM but its now realigned to get all the Spur goodness, so Pharo would inherit your changes in due course. Full disclosure: I'm trying to close old tickets to reduce our software inventory [1] - but I hopefully this is a good path for you also. [1] http://www.joelonsoftware.com/items/2012/07/09.html cheers -ben > >> 4. Decline to use it? > > Then I have to find different kind of work. :) > > >> Holger, What application are you using this for, and how are you >> managing to work with this at the moment? > > I am using a piece of C application that handles SCTP/SIGTRAN and > provides a TCP/IP relay for Pharo. > > |
> So it seems you only need VM changes integrated. How would you feel > about working directly with the vm-dev community to do this? A ticket > in the Pharo bugtracker is implicitly waiting for someone else to pick > it up and push it, but Pharo has only a few busy people to work on the > VM, thus your ticket there has languished >2yrs. There are more > non-Pharo vm-devs (who don't follow the Pharo bug tracker), so going > direct you might have a broader chance of getting it reviewed and > integrated. This might not have been so practical when you first > logged your ticket since at that time the Pharo-VM had diverged from > the mainline-Cog-VM but its now realigned to get all the Spur > goodness, so Pharo would inherit your changes in due course. > > Full disclosure: I'm trying to close old tickets to reduce our > software inventory [1] - but I hopefully this is a good path for you > also. > [1] http://www.joelonsoftware.com/items/2012/07/09.html > > cheers -ben Thanks ben. You are so right :) |
Free forum by Nabble | Edit this page |