Add ReplyNew TopicNew Poll

 API
#
http://zetaboards.pro/pages/zbapi/

I built a somewhat jQuery API like this for ZB and was wondering if something like this would be good for Jcink or needed. I don't want to start something that is in the works already. Obviously some of the features I added for ZB are already available here. The whole idea is to spend the finding the pertinent data on the page to return (you'll find it in the ZB API under the build function).

So, should I work on something like this or is this already in the works?
PM
#
I have to say that Junkbot has done a lot of amazing work with coding for Zeta, it would be great to see that work on here.

signature
The Friendly Bunch Forums

A Great General Community Based Forum For Everyone.
PM
#
A few years ago we were working on an API but not in the direction that you have gone with ZB. It wasn't external -- it was internal. We had calls to create new accounts, post messages, and it could all be done from an external application. And it was all functional, not design focused.

It would be cool to have something with features like this for example:

CODE
EASY HIDING

For developers and admins to easily hide forums, topics and private messages from members.

$zbapi.hide({f:['3348205']});


But we're not working on that. So, you're welcome to go ahead and I woud like to see what you do here. http://files.b1.jcink.com/html/emoticons/biggrin.gif

I do ask one thing: don't add any features that will require many persistent requests, or if you do, check with me first. We've had issues with some scripts that generated too much traffic against pages that simply weren't designed for persistent/many connections/constantly polling them. Or mass amount of users polling every 10-20 seconds. Hope that's understandable,

signature
email: admin@jcink.com :: blog: John C.
#
QUOTE
.. We've had issues with some scripts that generated too much traffic against pages that simply weren't designed for persistent/many connections/constantly polling them. Or mass amount of users polling every 10-20 seconds.


😇
whoops
PM
#
QUOTE (John @ Jun 4 2018, 02:48 PM)
A few years ago we were working on an API but not in the direction that you have gone with ZB. It wasn't external -- it was internal. We had calls to create new accounts, post messages, and it could all be done from an external application. And it was all functional, not design focused.

It would be cool to have something with features like this for example:

CODE
EASY HIDING

For developers and admins to easily hide forums, topics and private messages from members.

$zbapi.hide({f:['3348205']});


But we're not working on that. So, you're welcome to go ahead and I woud like to see what you do here. http://files.b1.jcink.com/html/emoticons/biggrin.gif

I do ask one thing: don't add any features that will require many persistent requests, or if you do, check with me first. We've had issues with some scripts that generated too much traffic against pages that simply weren't designed for persistent/many connections/constantly polling them. Or mass amount of users polling every 10-20 seconds. Hope that's understandable,


The hide feature was actually really cool and not too hard to implement. What it would do would be first to redirect anyone but admins and moderators from the particular page be that a category, forum or topic page (for ZB also for single post pages), and PM convos. It would also find all PM links on the inbox page with a particular ID and remove the closest row, or for the purpose of the notification system I built it would merge all the columns and rewrite the JSON PM title to the correct format "Mention by --- in the topic ---." This could also be an option to do when hiding things.

The limitations I see with this API would be that it would be restricted to themes which use the base templates or at least base classes and/or ids. Otherwise it would make it far too difficult to obtain the correct data. What I guess could be done would be to either require a JSON object for their theme denoting classes, or an idea that just popped up would be to add some basic hidden HTML to the end of each board wrapper which you can just copy and past and it would include all the variables for that wrapper... That might be a good idea.

Could you please also let me know which were the previously problematic pages? For the API I don't intend right now on creating any features in terms of displaying data and such. It will simply be a tool to ease developers in obtaining said data from pages, and some minor functionality available to them.

This post has been edited by Junkbot: Jun 4 2018, 02:14 PM
PM
#
There aren't specific pages per say -- anything that does a lot of polling when used en-masse has the potential to be a problem.

A worst case scenario example is a script for the alert system that someone wrote. They used the alert system json output option to write a notifier script. It would poll the site for new alerts constantly as long as the user's browser was open, even if they weren't on the site.

Had too many boards hitting that page over time causing a drain on resources; and I had no choice but to block the script. The system just wasn't designed to be hit like that.

Indeed the api would have to be limited to the default template in most cases and I agree it would be unreasonable if not 'impossible' to work it into every single template; here compared to zb we offer much more advanced customization options and many people DO utilize them. But there's certainly plenty who use the default templates; or only partially use the templates so it would still be useful for them too. Someone might use custom forum rows but not do much with the board stats for example.

signature
email: admin@jcink.com :: blog: John C.
#
I understand. No. I do not intend on doing any such persistent calls. If the user uses the API for such, unfortunately I cannot stop them, but I myself will only offer the base in terms of what you can do with it.

Streamlining querying, getting the pertinent data and outputting an object for use, things like that. Yeah, but as I said, what do you think of the idea of requiring templates to include a hidden block where all the <!-- |tags| --> are stored. For example on the topic page you would have one for the topic data and then one for each post and its data.
PM
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:
Share this topic:
« Next Oldest | Feature Requests | Next Newest »

Options Add ReplyNew TopicNew Poll