rabbitmq-swift interface

[johndpope]

Seems to be a lot of support for rabbitmq amongst server side developers at my workplace. With swift 3 around the corner - and breaking changes ending next week - could be a good time to consider rewriting this to support linux / swift for server side. It would be in IBM's best interest to get behind this library too. Looks like there's a SwiftAsyncSocket for swift 3. https://github.com/saltzmanjoelh/SwiftAsyncSocket

Perhaps breaking this up into another github project -

• adding some core contributors
• out of the gate - should use apple's swiftpm (good video overview here ->https://vimeo.com/174225592)
  • get listed here -> https://swiftpkgs.ng.bluemix.net/search#?keywords=queue&page=1

[michaelklishin]

No. Please be realistic: Swift 3 is not anywhere near maturity. "Breaking changes ending this week" is promising but that's not how we evaluate Swift readiness.

[johndpope]

Hi Michael, it's a shame github labels everything 'an issue'. This ticket was more of an opportunity to plan to revise code and explore benefits of upgrading - which may take years (or days) to close. It wasn't actually a -> you need to do this work.

Consider that operating open source projects - you have the opportunity to foster the development community to collaborate and contribute / maybe even give some space to the ridiculous idea that other people can come to the party and do the work for you.

Personally - while I love and cherish objective-c - my preference is to use swift so that future developers that come along don't inherit a tech debt. This is a wider conversation - perhaps a lower hanging fruit would be to expose the library to a swift interface.

[camelpunch]

Hi @johndpope. Can you clarify what you mean by "expose the library to a swift interface"? We already target Swift users and all tests are written in Swift.

[johndpope-karhoo]

I think Xcode could help with this. I'm not sure of best practices here. From what I've read around SDKs should provide users a swifty interface to consume the libraries. There's probably some more sensible ways to proceed here. The intention from my point of view is to hide the objective-c from developers that maybe coming from python or other server side libraries like ruby. They could use server side swift to build their apps - and plugin rabbitmq. This sounds like something you guys don't want to get behind at this point for whatever reason so I'm going to consider this ticket closed.

I think it would require (heaven forbid) removing the header files then having the implementation file reference the swift header. (There's probably a better way to do this) You could just throw it back on the end user to view the generated header and decrypt the objective-c.

The end result is a new 'swift' library

if you work out a way to do this programmatically - I'm all ears.

[michaelklishin]

Please take this to rabbitmq-users. RabbitMQ uses GitHub issues for specific actionable items engineers can work on, not questions or discussions. Thank you.

[michaelklishin]

This client library was developed to serve primarily iOS developers. Objective-C and Swift were both considered and Swift wasn't mature enough to proceed with it (it was just 6 months ago, which is hardly a long time for programming languages). Multiple iOS developers at Pivotal were involved in the discussion. Using Swift from Objective-C isn't nearly as nice as the other way around. This is something application developers don't have to worry about but something that makes a huge difference for library maintainers.

If this issue becomes important enough, our users will tell us. Currently the response is predominantly "thanks god this library exists and I don't have to use librabbitmq-c any more" or "thank you for not dragging all the Swift baggage into my project with this library".

Once Swift 3 (or 4, or N) actually becomes mature — as in, not developing libraries in it would be considered odd by most iOS developers — this client will be ported to it, or another one will be developed just for Swift. Those who want that to happen sooner are welcome to go to rabbitmq-users post specific and actionable suggestions about improving the Swift user experience in response to the @camelpunch's comment above.

[johndpope]

fyi - https://github.com/Awesome-Server-Side-Swift/TheList

[johndpope]

fyi - server side message q - https://github.com/John-Connolly/SwiftQ

[adib]

As Swift 5 is maturing (and will include binary compatibility), maybe it's time to revisit having a "pure swift" library that can cross-compile to run on Linux?

[michaelklishin]

I agree. Unfortunately our small team is very busy with other things in the next few months.

On Fri, 22 Jun 2018 at 08:21, Sasmito Adibowo notifications@github.com wrote:

As Swift 5 is maturing (and will include binary compatibility), maybe it's time to revisit having a "pure swift" library that can cross-compile to run on Linux?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/rabbitmq/rabbitmq-objc-client/issues/87#issuecomment-399323913, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAEQlOT1IvLd92ByAdsbRN861sxdITIks5t_H7igaJpZM4JS1iW .

-- Staff Software Engineer, Pivotal/RabbitMQ