Re: [Tiki-devel] Proposal of web push packages to be integrated into Tiki

Hi Alvin,

The websockets server app can be built into Tiki and reuse exiting Tiki 
components, libs, etc. It might not be standalone. So, both client and 
server will stay in Tiki.

Re: Notifications API - how do you receive a browser notification 
without a service worker? Also, where do you send the API push request - 
external service? I think we introduce a lot of dependencies here. 
Imagine an intranet Tiki behind a firewall - external services are 
unavailable there.

Regards,
Victor

On 5/11/22 6:42 PM, Alvin Bauma wrote:
> Hello Victor,
> Thank you for your very interesting feedback.
>
> I have a concern with Ratchet lib, if we have to follow the use case 
> that I want to implement, so we have to develop a small standalone 
> application that will be used as a server and Tiki will be seen as the 
> client in bi-directional communication?
>
> And also in any case, we will always use the Notification API to 
> display the notifications on the browser? without going through a 
> service worker.
>
> Best regards,
>
>
>
> Le mer. 11 mai 2022 à 16:29, Victor Emanouilov via TikiWiki-devel 
> <[email protected]> a écrit :
>
>     Hi Alvin (and others interested),
>
>     I did some research here and think Web Push is still not mature
>     enough to use. It is a WIP and only supported by part of the
>     browsers - https://caniuse.com/push-api
>
>     Also, the idea of running a service worker on the client side
>     makes me doubt it will be stable any time soon provided the
>     plethora of browsers and client-side systems, mobile, embedded
>     clients, etc. Historically, it has always been better to abstract
>     complexity on the server side rather than client side. This is
>     just a personal view. Running a service worker on the client side
>     allows you to receive a push notification even if you are outside
>     the Tiki site which opens some use-cases but I think adds
>     unnecessary security complications and also system implementation
>     complications.
>
>     Thus, can I recommend using the more traditional (but still
>     modern) bi-directional communication channel of websockets? It is
>     now well-established and I think has more browser support. This
>     way, we get rid of requirement to have subscription endpoints and
>     can integrate as a self-contained solution into Tiki.
>
>     Please check the wonderful Ratchet lib (http://socketo.me/) built
>     on top of ReactPHP (https://reactphp.org/) event-driven lib.
>     Projects are well supported and widely used. Think of Ratchet as
>     socket.io <http://socket.io> (nodejs app) in PHP. We have all the
>     libs in PHP, we can integrate in Tiki. We need a running
>     standalone server Ratchet app which can be proxied via
>     apache/nginx or exposed on another public port on the server.
>     There are OS and Pecl extensions to make it quite fast and also
>     deployment specifics (http://socketo.me/docs/deploy) but we can't
>     get rid of the complexity of the bi-directional communication. If
>     we implement something like this, we can open many use-cases
>     besides XYZ is typing... scenario. E.g. we currently have an issue
>     waiting for long-running tasks on the web (e.g. Tiki manager
>     initializing or upgrading existing Tikies), so we can use
>     websockets to keep the connection open, push progress immediately
>     to the browser and still keep the HTTP connection open, so user
>     can continue using Tiki site while waiting. Lock/unlock mechanisms
>     to prevent content overwrites are another example that benefits
>     from this solution.
>
>     Btw, we can even build an additional app on top of ReactPHP to
>     handle our background jobs scheduler (currently partially hacked
>     as a set of cron jobs). So, I can see multiple benefits of going
>     this way rather than Web Push.
>
>     Regards,
>     Victor
>
>     On 5/5/22 11:13 AM, Alvin Bauma wrote:
>>     Hi Jonny, Thanks for your feedback.
>>
>>     After going through several documentations on integrating web
>>     push in PHP, I found that my first proposal on the list was the
>>     best and above all easy to integrate.
>>
>>     As the functionality may start in Tiki24.x and 25.x, we won't
>>     really have a problem with the PHP version required for this package.
>>
>>     We are just waiting for community approval to decide if we can
>>     proceed with the integration of this package.
>>
>>     Thank you.
>>
>>     Le lun. 2 mai 2022 à 16:06, Jonny Bradley via TikiWiki-devel
>>     <[email protected]> a écrit :
>>
>>         Hi Alvin
>>
>>         Thanks for this initiative - i started looking into it
>>         recently to see if we could add a "someone is typing a reply"
>>         thing in the comments/forum posts (so we look all cool and
>>         trendy! 😎) but saw we are missing this as a library/feature.
>>         Several posts i read said it's simple enough to implement
>>         your own, but i wasn't convinced ;)
>>
>>         Presumably it should use, and be integrated in to, the new
>>         API Victor added for 24.x https://doc.tiki.org/tiki24#API so
>>         i guess his input would be rather useful.
>>
>>         Apart from that, the first one on your list
>>         https://dev.tiki.org/Proposal-of-web-push-packages#minishlink_web-push
>>         looks like the best fit for us if there are no other
>>         significant differences (and we only need it for php 7.4+ in
>>         tiki 25/24+ right?)
>>
>>         Thanks again
>>
>>         jonny
>>
>>
>>
>>         > On 2 May 2022, at 12:19, Alvin Bauma
>>         <[email protected]> wrote:
>>         >
>>         > Hi,
>>         >
>>         > I'm currently working on Push Notification in Tiki, so I
>>         wanted to add a PHP library to handle sending notifications.
>>         > I did some research and I came across some interesting
>>         libraries that I present in the page:
>>         https://avan.tech/proposal-of-web-push-packages.
>>         >
>>         > Please therefore analyze with me the choice of the library
>>         that we must integrate.
>>         >
>>         > Regard,
>>         >
>>         > --
>>         > Alvin BAUMA KALAMO
>>         > Software engineer
>>         > Phone/WhatsApp :     +243 995 502 981
>>         > Mobile :                     +243 840 409 642
>>         > Email : [email protected]
>>         > _______________________________________________
>>         > TikiWiki-devel mailing list
>>         > [email protected]
>>         > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>>
>>
>>         _______________________________________________
>>         TikiWiki-devel mailing list
>>         [email protected]
>>         https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>>
>>
>>     -- 
>>     *Alvin BAUMA KALAMO*
>>     *Software engineer *
>>     Phone/WhatsApp : +243 995 502 981
>>     Mobile : +243 840 409 642
>>     Email : [email protected]
>>     Portfolio : _https://torre.co/alvinbm_
>>
>>
>>     _______________________________________________
>>     TikiWiki-devel mailing list
>>     [email protected]
>>     https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>     _______________________________________________
>     TikiWiki-devel mailing list
>     [email protected]
>     https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
>
> -- 
> *Alvin BAUMA KALAMO*
> *Software engineer *
> Phone/WhatsApp : +243 995 502 981
> Mobile : +243 840 409 642
> Email : [email protected]
> Portfolio : _https://torre.co/alvinbm_
>
>
> _______________________________________________
> TikiWiki-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel