I sent this to some APE collaborator recently, but I do want to have more 
feedback on this.

Many problems have been fixed recently concerning APE. For exemple, the 
missing docs on the new website and the instal/build problems with new deb 
packages (I didn’t hear back from them, I assumed they work fine). Since 
the server part is pretty stable, I think the next big thing we probably 
need to focus on is the APE javascript client, *APE_JSF*. 

The current APE JSF is a bit… outdated. It does work fine, but the setup, 
with the client/core distinction, is a bit "weird". Moreover, the demos 
shipped with JSF all use Mootools and classes JQuery (or vanilla JS) don’t 
support. And seriously, let's face it, Mootools is out. jQuery is the most 
used framework today (With vanilla javascript always the better option).

The curent demos on the APE website are also difficult to understand, even 
if you know Mootools. And we all know the demos are the key to understand 
how APE work. There's also a compatibility issue. For example, on the APE 
website I had to put the demos in an iframe because Mootools (from the 
demos) wasn’t playing nice with JQuery (from the template/Bootstrap). 

The JSF doesn't require a simple updated (it haven’t been updated in more 
than 3 years now), it need a complete rewrite. There’s two Pull Request 
from Peter and I waiting on Github (
https://github.com/APE-Project/APE_JSF/pulls), but while those fix some 
stuff, but it’s far from a complete rewrite the JSF needs to merge the 
client and the core while getting rid of Mootools.

The alternative to a complete rewrite would be using Pablo’s alternate 
client named *ApePubSub (APS) *(https://github.com/ptejada/ApePubSub). APS 
is modern, written in vanilla javascript and well documented. It fix some 
existing issues with JSF while introducing new features (user/channel 
properties update, sessions management, cross-domain, easier setup, vanilla 
javascript etc…). For those not familiar with APS, I wrote a complete 
document/example explaining the difference between APS and JSF (and why APS 
is awesome). You can find this on GitHub: 
https://github.com/lcharette/JSF-vs.-APS---Move-demo. The only setback is 
backward compatibility.


*With that in mind, I propose we promote Pablo’s ApePubSub as the default 
APE javascript client. *


Replacing JSF with APS is the most logical thing to do right now I think 
considering the time and energy it would require to rewrite the JSF 
completely. If we go ahead with this plan, there’s gonna be some breaking 
changes involved for sure. I see the transition going this way: 

   - We archive the old JSF, demos and documentation 
   - The current server source code is released as 1.1.3. Since the default 
   server side javascript need to be changed, 1.1.3 would be the last version 
   of the server shipped with support for JSF out of the box. A new 1.2 
   version of the server would then be shipped with APS default server side 
   scripts. It should be noted both framework will still be compatible with 
   both version of the server, the version change only purpose being avoiding 
   confusion. 
   - Pablo already did an amazing job documenting his work on the APS wiki. 
   The APE website would redirect the client documentation to APS wiki OR the 
   APS documentation could be copied on the website. 
   - Update the demos on the APE website. Pablo already have some nice 
   demos woking with and without JQuery/Bootstrap. We could create new demos, 
   convert the existing ones or use Pablo’s demos. (I already have the move 
   demo converted/updated, I believe being able to convert/update the Pixelbox 
   demo too). 
   - Update the website text and documentation + the wiki (it already need 
   updating) 
   - Finally, I think we should keep the ApePubSub name and not rebrand it 
   « JSF 2.0 » to respect Pablo’s great work. 


An alternative to this change would be to ship the server without any 
server side javascript and let the clients (JSF & APS) ship those default 
scripts with explanation on how to install them. But this alternative goes 
against the idea of shipping a complete solution. The other alternative 
would be to support and promote both framework, which may lead to 
confusion. Or doing nothing is always a solution...



On a side note, I experimented with node.js recently. While it’s a nice 
product with a ton of support, I feel there’s a little something missing 
compared to APE (User management; The fact that APE doesn’t require server 
side code for basic stuff, etc). With some updated stuff (APS, new demos, 
etc) and a little time, I truly think we can make APE cool again :)


Let me know what you think,

  - Louis

-- 
-- 
You received this message because you are subscribed to the Google
Groups "APE Project" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/ape-project?hl=en
---
APE Project (Ajax Push Engine)
Official website : http://www.ape-project.org/
Git Hub : http://github.com/APE-Project/

--- 
You received this message because you are subscribed to the Google Groups "APE 
Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to