getting user info from every member

[Tim Camara]

Mar 13, 2014 7:41:26 GMT -8 Wormopolis said:

You basically described the Alters plugin.  except characters are stored in plugin settings.

Great minds think alike? 

[Peter]

Wormopolis

Ah right, sorry, I didn't even know how yours worked, or what it did.

[DarkPikachu]

hmm...

any way to do:
var id = get_user("@loggren");
when he's not on the page??

[DarkPikachu]

*sigh* I'll lower my standards only a bit...

I suppose I could use a post key to store a dictionary:
{ '*user*': '/user/*id*' }

and I could retrieve the info from that

EDIT:
I can't store the info for the characters in the post key
because that could easily overflow the key when using alot of characters...
(especially if the characters use CSS or large links in their code)


EDIT2:
well I'm here t admit... I was wrong about super keys >3<

regular keys can hold up to roughly 4KB, while super keys hold about 32KB...

now that satisfies me for what I need, but there's still 2 more hurdles to jump:
(because it's not about me and what I want for my forum, it's about me making something that works like everyone likes)
- loggren has enough RP characters to fill 3 books worth
- I don't like limitations, excluding machine capacity

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Mar 13, 2014 10:56:18 GMT -8 DarkPikachu said:

*sigh* I'll lower my standards only a bit...

I suppose I could use a post key to store a dictionary:
{ '*user*': '/user/*id*' }

and I could retrieve the info from that

EDIT:
I can't store the info for the characters in the post key
because that could easily overflow the key when using alot of characters...
(especially if the characters use CSS or large links in their code)


EDIT2:
well I'm here t admit... I was wrong about super keys >3<

regular keys can hold up to roughly 4KB, while super keys hold about 32KB...

now that satisfies me for what I need, but there's still 2 more hurdles to jump:
(because it's not about me and what I want for my forum, it's about me making something that works like everyone likes)
- loggren has enough RP characters to fill 3 books worth
- I don't like limitations, excluding machine capacity

If you think you can overload the super key, you will have to limit how many rp characters they can use. The reason being that if you overload a super key, it renders all of your plugins useless. Pretty much. 

[Wormopolis]

super USER keys hold 4K. super FORUM keys hold 32K

Tim Camara can correct me if I am wrong

[DarkPikachu]

Mar 13, 2014 23:47:28 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

If you think you can overload the super key, you will have to limit how many rp characters they can use. The reason being that if you overload a super key, it renders all of your plugins useless. Pretty much. 

meh...

I'll just use localStorage...
I do believe the minimum for that is 5MB which should be enough for quite a few 1500 users at least.

but if more should end up being needed later on, I'll switch to fileSystem.
(I've seen a few places recommend this, and it should be supported across most modern browsers now)

[DarkPikachu]

ok, so I now know why you don't want me using iframes.
so it's about iframes messing with ad-sense, and not entirely about server-strain...

why didn't you just inform me to begin with?
note: '?' means rhetorical '??' is an actual Q

may I suggest a method for disabling ad-sense for pages in an iframe.
ACTUALLY, may I suggest a simple method to load a page with alot less data through an iframe.


but anyways... I'm not into iframes anymore.
I was informed about AJAX calls which I can use to get my info.

may I request permission to make these ajax calls dynamically?? (since you want a user action)
I already have the interface for deciding which calls will need to be one to keep them as minimal as needed.


I can fall back to user action, but I can't say it'll be liked by members.
(users will get an annoying notification about not having these users info)

all this is, is a single 'ok' button that activates the automated process only if there are unknown users on the page.


also, could I get an AJAX example plox.

[Tim Camara]

Mar 18, 2014 7:47:57 GMT -8 DarkPikachu said:

so it's about iframes messing with ad-sense, and not entirely about server-strain...

Nope, it affects ads as well, but it's really about server strain.  With this kind of a plugin, I could easily make a post that would get any member that clicked your dialog auto banned PB-wide.

Mar 18, 2014 7:47:57 GMT -8 DarkPikachu said:

may I suggest a method for disabling ad-sense for pages in an iframe.
ACTUALLY, may I suggest a simple method to load a page with alot less data through an iframe.

You may certainly suggest a method, but we don't load pages through iframes (except the WYSIWYG), and doing so in a plugin or code is still breaking the TOS.

Mar 18, 2014 7:47:57 GMT -8 DarkPikachu said:

may I request permission to make these ajax calls dynamically?? (since you want a user action)
I already have the interface for deciding which calls will need to be one to keep them as minimal as needed.

I can fall back to user action, but I can't say it'll be liked by members.
(users will get an annoying notification about not having these users info)

all this is, is a single 'ok' button that activates the automated process only if there are unknown users on the page.

Permission denied.  I suggest you review the Developer Guidelines.

Mar 18, 2014 7:47:57 GMT -8 DarkPikachu said:

also, could I get an AJAX example plox.

Without details, that's like asking for an HTML example.  The easiest way to trigger an AJAX request is with jQuery: api.jquery.com/jQuery.ajax/.

[Virgil Sovereign]

If you wanted to be clever about it, you could try a semi-supervised approach using a forum key.

Suppose you could guarantee that data for one character would not exceed 1 KB, which is a plentiful amount of data indeed. And suppose that instead of storing a character database in the forum key, you stored edits to characters using an only-as-needed format. 'Edits' would include new characters, edits to existing data, character deletes, etc.

In addition to this, you would have a character master table (presumably in HTML) defined somewhere in a plugin header. Alternatively, you could store the master table in a JavaScript component, which would have the benefit of being cacheable. When needed, your plugin first consults the master table for a character list/data, "patching in" edits from the forum key on the fly to reflect any recent changes to character data.

Your admin account (and any other admins you deemed worthy) would also have access to a client-side tool that would produce a new master character table by merging the existing MCT with recent edits in the forum key, outputting some HTML or JS that you could simply dump into your plugin. Once the new MCT was in place, you could wipe the forum key and proceed "fresh". As long as somebody updated the MCT frequently enough to avoid > 32 KB of edits accruing in the meantime, you'd have a system wherein changes in character data would be instantly visible to all users, even while your database could presumably grow to sizes vastly in excess of 32 KB.

You would have the added benefit of being able to vet (selectively approve or deny) any edits, and some basic security in the sense that if a malicious user tampered with the forum key, you'd only lose the most recent batch of edits rather than the entire MCT.

The obvious problems with this approach are twofold: 1. There are practical limits on how much data you could store in the MCT. I don't know what Proboards allows or is willing to allow in terms of .JS file sizes. The Proboards client codebase is about 2MB, hence something as large as 500 KB might be considered reasonable, provided it was cacheable. That would suffice to store at least 500 characters.  And 2. Anything involving a forum key would need to be synchronized by your own code. You'd have to have at least some basic logic to ensure forum key updates weren't lost in high-traffic situations.

[DarkPikachu]

how bout this Tim Camara, you give me a list of negatives from what you know,
and I'll work in a logic that bamfs the negatives so we can have something that actually works.

@Virgil Sovereign: interesting idea


EDIT:
also Tim Camara, what was your post idea that could get someone banned globally??

if it's loading 15 iframes in a single post, keep in mind they're delayed.
also, the amount would be a global delay from the entire thread page.


EDIT2:
also...

Mar 18, 2014 15:07:36 GMT -8 Tim Camara said:

I suggest you review the Developer Guidelines.

I hate it when people do that.

I've already reviewed them before I started coding my first plugin.

at least give me something that tells me what you've considered and gone against for what reasons
so I can negotiate with you and get this thing working properly.
(where it WON'T cause error)

don't mis-judge me, I know quite alot about the net,
and am working on more than a few overwhelmingly complex projects.
see spoiler if you're curious about a few of them:

SPOILER: Click to show

- a recompiler that can decompile assembly into whatever language you want (extendable for future languages)
- AII, an AI for video games (you can interact with it and it'll behave, and follow your commands EXACTLY like another human would.)
- a voice simulator for Pikachu (small side-project for AII's speech simulator (won't sound robotic))

there's about 5 more, but I think I've said enough

so the LAST thing I'm gonna do is get someone banned. >

[Virgil Sovereign]

DarkPikachu: I think the issue is more along the lines of Proboards not having the resources to vet individual proposals. An iframe pulls down a large amount of content, and Proboards has to pay for that bandwidth. They don't have time to check individual proposals and grant selective exemptions.

If my suggestion above doesn't appeal to you, why not take Tim's earlier advice and get a server of your own. There are cloud services out there that will give you access to a LAMP stack or whatever backend setup suits your fancy for $5 a month. In a matter of days you can create your own simple database and write some basic set/get scripts, then store as much data as you want and access it as much as you want.

There's a bit of a learning curve, but consider it a challenge and an opportunity. Best of all, you'll have come up with an elegant solution to your specific problem, not something cobbled together with hidden iframes spinning through pages.

[Tim Camara]

Mar 18, 2014 22:07:04 GMT -8 DarkPikachu said:

how bout this Tim Camara, you give me a list of negatives from what you know,
and I'll work in a logic that bamfs the negatives so we can have something that actually works.

- No iframes
- No making AJAX calls without user input
- No making 1 call per unloaded user on the page, regardless of delay

Mar 18, 2014 22:07:04 GMT -8 DarkPikachu said:

also...

Mar 18, 2014 15:07:36 GMT -8 Tim Camara said:

I suggest you review the Developer Guidelines.

I hate it when people do that.

I've already reviewed them before I started coding my first plugin.

The reason I keep referring you to it is you keep asking if you can do things that violate the guidelines.  The answer is and always will be no.

Mar 18, 2014 22:07:04 GMT -8 DarkPikachu said:

at least give me something that tells me what you've considered and gone against for what reasons
so I can negotiate with you and get this thing working properly.
(where it WON'T cause error)

Peter and Virgil Sovereign have both suggested possible workarounds.  My recommendation is to abandon the lazy/JIT loading of data, instead opting to store the data as soon as a user adds/updates it.  Store the data to either a super forum key, or if that's not enough space, some external data storage location (I know you hate me linking the Developer Guidelines, but they specifically allow loading data from external sources, so long as that data is loaded asynchronously).  This way you can retrieve all the character data needed for a thread with a single call.  Bonus here is that if your data is stored externally, you don't have to make the user click on anything to load it (since it's not using PB servers, it's not subject to that restriction).  Basically a slight modification of Virgil Sovereign's idea to take advantage of the benefits of external data storage.

Edit:
I'm pretty sure Virgil Sovereign is in my head.

[DarkPikachu]

following my old idea of iframes...

ok, like I said, I'm trying to use iframes as little as possible...
I've already mentioned I'm using localStorage,
so once you visit a page that has the user's data, you'll have that copy forever.

but now what happens when there's someone referenced by another user who's data is not in your data.
THAT's what I'd need to use a HIDDEN iframe for.

also, there's ONLY 1 iframe on the page limited to this plugin, and it's ALWAYS hidden.
for the amount of users on the page who's data isn't in your localStorage:

• 1: the iframe will be created linking to the first user's profile on the list.
  (initially the plugin DOESN'T load the iframe if it doesn't need to)
  
• 2: 1 second later, the iframe will be updated with the next user, and so-forth.
  
• 3: once finished, the iframe will be removed.
  

that is my intentions if I go with that idea.


but as for the new idea,
I intend to replace the iframes with the ajax calls to get the data.

pretty pointless to make a user validate this...


I see why I can't use the iframes with this method due to the ad-sense being screwed up by them...
so... why not ajax calls??

Please don't be a simpleton and say "because it's against the TOS".
The world is many shades of gray, not black and white.


also...

Mar 19, 2014 8:08:56 GMT -8 Tim Camara said:

- No iframes
- No making AJAX calls without user input
- No making 1 call per unloaded user on the page, regardless of delay

is not a list of negatives.

if you want something effective towards me, make me see why I can't, instead of just telling me I can't.
(give me something I can't argue with)


for example:
Q: Why can't I use iframes?

A0: It's against the TOS
Objection: anything against the rules can be overridden if proper precautions are taken.

A1: Too many calls to the server in a short amount of time
Objection: this has been ruled out by delaying the src calls using only 1 iframe.

A2: It screws up ad-sense
I can't go against this until ad-sense is improved.

so taking that into account, here's my second question:

Q: Why can't I allow AJAX calls w/o user input? (using the same interface as with iframes)

A0: It's against the TOS

A1: Too many calls to the server in a short amount of time
Objection: this has been ruled out by delaying the calls.

A2: extra Bandwidth
Objection: pending


to make up for the bandwidth, there was an idea I had long ago to help you guys out...
I wanted to increase the ads displayed on my forum and help you guys get more money out of it.
(I would hide them in a 1x1px DIV positioned behind the top left of the existing ads)

would that screw things up on your end??
cause if not, in a way, I'd be paying you for that extra bandwidth.

[Boy_Wonder]

The fact is its against the TOS regardless of your objections. If EVERY coder went "oh I have this smart idea for this code that would rely on this" then very quickly proboards would turn into a pay service. I'm not Tim or anyone who handles coding but to me you either deal with the restrictions and stop trying to argue with them or give up on your idea as unfeasible, or find away that's WITHIN the preset TOS that all coders agree to for developing your plugin. Doesn't matter if you can find Bad butt reasons as to why you should get your own way, if you want to try and run something that can match proboards and allow full freedom yanno.

I'm not a Javascript etc coder, my language is Divs, floats and css. However one thing I do recall a teacher saying - Rules are meant to be broken. If they are not meant to be broken they are restrictions that can guide you to a more creative outcome.