Rename to ably-php-rest

[mattheworiordan]

@kouno the convention we have used for other libraries is to suffix the library with -rest if it only supports REST functionality, see https://github.com/ably/ably-python-rest, https://github.com/ably/ably-ruby-rest. I think we should do the same here.

WDYT?

[kouno]

Hum. I was curious and looked up on the ruby library, and I'm not sure it's the right approach.

1. the ably-ruby-rest library was created with the explicit goal of removing the EventMachine requirement:
   https://github.com/ably/ably-ruby-rest/tree/a74c3ce40113abdd676832e5616dd57e5241abc6#ably. Sure, sounds fair, but I don't see the PHP library doing such things in the foreseeable future. Also, other libraries already have their own evented/concurrent implementation. So should they use this convention too?

2. the ably-ruby-rest library requires the ably-ruby library as a submodule (see https://github.com/ably/ably-ruby-rest/tree/a74c3ce40113abdd676832e5616dd57e5241abc6/lib/submodules) which looks like backward logic. It should have been ably-ruby which requires ably-ruby-rest (and eventually ably-ruby-realtime if we push segregation further?). If we were to do this for ably-php, I would expect to still have ably-php which reference ably-php-rest but this would just be a repository containing a single submodule... Which sounds like a waste.

3. I was under the impression that the realtime and rest part of our libraries were pretty tied up by the different objects they share (messages, authentication, pagination...). For example, the python library at the moment contains objects that I would very well see on both rest and realtime sides https://github.com/ably/ably-python-rest/blob/b444d820350da083a50b36f7286c66b497176c4a/ably/transport/defaults.py. Would you create another submodule to share these classes? Sounds like it would be a useless overhead.

4. the Python and Ruby libraries are the only one doing this, right? I'm not sure I would go that way for any other libraries. For example, Golang have a segregation done by folders already. When you import a folder it will load the entire namespace in this folder directly. rest and realtime are already pretty well separated.

All that said, if we ever are at a point where we have the ably-php library implement the realtime part, and we use a third party library like EventMachine, then yes, we could push the codebase to a rest-only submodule which doesn't require it.

cc/ @bladeSk

[bladeSk]

I don't have much insight into non-PHP versions of Ably client lib, but I can say for PHP, that it's rarely used for realtime applications. It is possible, though. See Ratchet.
Ably-php-rest sounds reasonable. The realtime library would be probably built on top of it, as its features are a superset of the REST lib.

[mattheworiordan]

The ably-ruby-rest library requires the ably-ruby library as a submodule

This is definitely not the right way of doing this if we indeed wanted Realtime to be a superset of Rest in isolation, however given the reason the Ruby REST library was created (only to remove dependencies) I feel our approach is right because working on any features that may effect both REST & Realtime can be done in a single repository. If REST was a sub-module working on changes in both would be a nightmare.

Would you create another submodule to share these shared classes?

No, god know!

The Python and Ruby libraries are the only one doing this, right?

Yes, for now, although Python does not support real-time for now, only REST.

I think largely I agree with you @kouno, unless we explicitly need a REST only version of a library, then we should just use the logical name ably-[language/platform].

So lets leave ably-php as is, I will rename ably-python-rest to ably-python and if we ever introduce a realtime version of either and then as a result need a REST only version we will create a ably-php-rest version.

Thanks both for your thoughts.