1 (edited by Argyle 2005-01-29 16:29)

Topic: Multiple Quotes

How about the possibility to quote more than one post at once?

Just like the 'Delete multiple posts' function maybe some possibility to check certain posts and then add them all at once to the message box.
As several

one after another of course.

One of the lessons of history is that nothing is often a good thing to do and always a clever thing to say.
~ Will Durant (1885 - 1981)

Re: Multiple Quotes

someone made a mod for this for 1.1.x

3

Re: Multiple Quotes

Wonder how hard it'd be to port it over.

"You start coding. I'll go find out what they want." - Computer Analyst to Programmer

Re: Multiple Quotes

That would be quite a nice feature.

Re: Multiple Quotes

maybe a neat way to do it would be a javascipt solution on the post reply page which meant you could click quote on the topic review and it added it to the end of the post

Re: Multiple Quotes

Yes. But Javascript this, Javascript that, in the end the server is quite light weighted, but you need to download 150k to display one page sad

Re: Multiple Quotes

its only 1 bit of javascript, theres hardly any javascript on punbb, and it woouldn't affect the quick post only the post.php display and most people cache files...

Re: Multiple Quotes

I was saying this because there is the "thread read|new" issue too, and it seems that more and more things are pushed to the client to keep punBB "light" but in the end it would make it heavier to use than others.

Re: Multiple Quotes

Just a personal note:
Cant say i like JavaScript smile

One of the lessons of history is that nothing is often a good thing to do and always a clever thing to say.
~ Will Durant (1885 - 1981)

Re: Multiple Quotes

Jérémie wrote:

I was saying this because there is the "thread read|new" issue too, and it seems that more and more things are pushed to the client to keep punBB "light" but in the end it would make it heavier to use than others.

i wasn't suggesting it to keep it light but to keep it tidy, check boxes on every post don't look very pretty

Re: Multiple Quotes

I can't say I generally like JavaScript heavy applications myself, but it is undoubtably where the web is going. I don't think having servers that supply raw data and clients doing all the processing is that far away anymore. Just have a look at Gmail. You all like that don't you?

"Programming is like sex: one mistake and you have to support it for the rest of your life."

Re: Multiple Quotes

makes alot of sense for sites with large load, i mean it basically shares it between all the computers browsing

13 (edited by Jérémie 2005-01-30 00:38)

Re: Multiple Quotes

Rickard wrote:

I can't say I generally like JavaScript heavy applications myself, but it is undoubtably where the web is going.

Not with old school modems :-)

I don't think having servers that supply raw data and clients doing all the processing is that far away anymore.

I agree on the theory, very much. With some restraints on what's asked of the clients (I really *don't* want to see a "minimal cpu/ram/video configuration" in front of webpages), I think it's a good idea mainly because that would put much more control into the hands of the client (is proprietary protocols don't take over), and because when a server serve 300 clients, 300 low ends computers are way more powerful than one or two high end server. It's cheaper, so it's good for free and personnal internet.

The thing is, I don't see that in present days technology. How do you do that ? As far as I know, these days you have to use Javascript (or something similar). On some instances it may be good, because the download and execution time of the script is inferior with that technology. But it's rare. On most case, it's quicker for the client to do the work server side.

Actually, it depends on how you see your punBB "speed" quality. Speed of server side execution ? Speed of how many clients you might serve at on time with a specific server ? Speed of client learning curve ? Speed of client everyday's use ? Speed of content delivery ?

"Speed" and ease of use can be very similar, if you have to load 5 pages to do something, it's probably speedier to do it on the first instance in one page.

On this particular feature, I don't know if it's possible to load a javascript with a javascript. I explain myself : multiple quoting can be quicker and better on the client side. But you don't need multiple quoting on every day, on every post, on every HTTP GET you use (well I almost do on some forums, but I'm a freak tongue). So is it possible to have a link or a button somewhere, once you are in reply mode, that would load a "multi quote script" on demand and this script would insert appropriate quoting when you click on the others posts in the thread ?

So the first script, it's a kind of a loader machine. Maybe 2 or 3 lines of code, very light. And the second script is loaded only when you need it, with no Apache socket/sessions waste, no bandwith waste, and so on.

In fact, that would be a nice profile/config feature. Some kind of "external JS plugins" that the admin can active or desactive by default, or by categories/forums, and the user can select (and so override admin) if it's activated or de-activated by default for him.

Not sure if I'm understandable...

Just have a look at Gmail. You all like that don't you?

Never used it, I don't need it and I'm not fond of people reading my emails :-)

Re: Multiple Quotes

i think the code to copy text from a div to a textbox would only be a couple of lines anyway literally i might have a look if i get time

Re: Multiple Quotes

Yep, my posts were broader. If you want you might as well split the thread to take my OT in there right place.

Re: Multiple Quotes

Jérémie wrote:

Not with old school modems :-)

If anything, modem users would benefit from a client side solution. Only sending raw data to the client and then doing all the processing on the client would drastically reduce the bandwidth use. The initial page view might take a bit longer as the client side scripts are downloaded, but then the browser cache takes over.

Jérémie wrote:

The thing is, I don't see that in present days technology. How do you do that ?

It's very much possible. Why wouldn't it be? You could use e.g. Javascript to process data supplied by a webserver.

Jérémie wrote:

As far as I know, these days you have to use Javascript (or something similar). On some instances it may be good, because the download and execution time of the script is inferior with that technology. But it's rare. On most case, it's quicker for the client to do the work server side.

The biggest performance problem on the web today is unsufficient server performance. Have a look at your CPU usage while browsing the web. It hardly ever goes over 10%. If we could utilize this idle processing time, webservers could go back to doing what they do best and that is to serve content.

Jérémie wrote:

Just have a look at Gmail. You all like that don't you?

Never used it, I don't need it and I'm not fond of people reading my emails :-)

Who would be reading your e-mails? Google?

"Programming is like sex: one mistake and you have to support it for the rest of your life."

17 (edited by Jérémie 2005-01-30 03:35)

Re: Multiple Quotes

Rickard wrote:

If anything, modem users would benefit from a client side solution. Only sending raw data to the client and then doing all the processing on the client would drastically reduce the bandwidth use. The initial page view might take a bit longer as the client side scripts are downloaded, but then the browser cache takes over.

True indeed, to the point where the user quit the waiting because it's too long. Below that point, all good. Hence the "loader on demand".

On that "point", on real everyday use of the web, it's very hard to determine, especially from your point of view (delivering software). You have to take into account the things a "basic webmaster' want to add, the others broad basic pre-requisites scripts (like IE7). Not much margin to work with.

Rickard wrote:

It's very much possible. Why wouldn't it be? You could use e.g. Javascript to process data supplied by a webserver.

First of all because some users de-activate javascript, or use a non-javascript client. If you want javascript to be a pre-requisite of casual surfing, you have to forget them.

But that's for some basic apps, on the other hand the recent proliferation of PHP web game would gain a *lot* with more javascript (for some time now I play a little hilarious french game, like a satiric dungeon monster bashing, it's maybe 5 mns a day. All the actions in the game result in a reload of the page ? 100% server side ? that's a huge waste).

But for some features on a forum, like the thread read/not read I was refering too, I'm really not sure javascript is the answer (and in that case I'm really sure it's not as much a feature as it is a definition of the tool, i.e. a forum). I may be wrong, that's why I'm testing it, but ...

Rickard wrote:

The biggest performance problem on the web today is unsufficient server performance. Have a look at your CPU usage while browsing the web. It hardly ever goes over 10%. If we could utilize this idle processing time, webservers could go back to doing what they do best and that is to serve content.

Again, I agree on the theory; not the idea that could be done with nowadays protocols and standards. But I could be wrong, for example I don't know the bandwith and server consumption of XUL.

And there is another trouble with wide and heavy client side, that's new hardware client. Let's take commons forum features, and say put half of them client side. Are you sure a pda or a pocket phone can handle that much ? They will, someday. But right now, you add an item of worry for webmasters. They have to worry about browsers bugs, plateform bugs, end-user needs (as in real, actual and reasonnable ones) and desires (as in futiles useless gadgets), faulty or cryptic writing of standards, server bugs, user hardware, user bandwith, server bandwith, and I forgot some. Adding user cpu power at hand ? Ouch ^^

Jérémie wrote:

Who would be reading your e-mails? Google?

That's what they do to target ads Email is cheap, storage too, I don't see the needs for gmail. I admire their implementation of mail threading (something Qualcomm did iirc but never implementend on Eudora, I still don't know why), but that's it. I don't use webmail or IMAP, so I don't need 1gB, and if I did use IMAP that would be quite ridiculous (I have around 600mB of emails, not counting attachements, that's several gB with them). But that's me, if some people need to save $2 or $3 to have a decent email provider that's there choice :-)

Re: Multiple Quotes

Jérémie wrote:

But for some features on a forum, like the thread read/not read I was refering too, I'm really not sure javascript is the answer (and in that case I'm really sure it's not as much a feature as it is a definition of the tool, i.e. a forum). I may be wrong, that's why I'm testing it, but ...

Well, personally, it's a feature I don't miss at all. I agree that JavaScript might not be the ultimate way of implementing the feature, but nonetheless, I'm impressed with Shawn's mod and the fact that it works like a plugin. If I ever were to add the feature to PunBB, I would definately store the data in a cookie. There's nothing that hurts MySQL performance quite like frequent updates.

Jérémie wrote:

And there is another trouble with wide and heavy client side, that's new hardware client. Let's take commons forum features, and say put half of them client side. Are you sure a pda or a pocket phone can handle that much ? They will, someday. But right now, you add an item of worry for webmasters. They have to worry about browsers bugs, plateform bugs, end-user needs (as in real, actual and reasonnable ones) and desires (as in futiles useless gadgets), faulty or cryptic writing of standards, server bugs, user hardware, user bandwith, server bandwith, and I forgot some. Adding user cpu power at hand ? Ouch ^^

If anything like this were even considered, it would of course have to work across all platforms. I'm not saying that would be easy or that anyone is even considering it, I'm just trying to say it is the way the web is going.

Sure, some people disable JavaScript or use funny browsers such as lynx or links, but so be it. More and more services require both cookies and Javascript. Gmail is one example.

Jérémie wrote:

That's what they do to target ads Email is cheap, storage too, I don't see the needs for gmail. I admire their implementation of mail threading (something Qualcomm did iirc but never implementend on Eudora, I still don't know why), but that's it. I don't use webmail or IMAP, so I don't need 1gB, and if I did use IMAP that would be quite ridiculous (I have around 600mB of emails, not counting attachements, that's several gB with them). But that's me, if some people need to save $2 or $3 to have a decent email provider that's there choice :-)

The thing I like about Gmail is the way it is implemented. I don't care about the 1 GB of storage. It really feels as if you're working in a proper applications and not just a web UI.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

19

Re: Multiple Quotes

I did this for 1.1.x, actually. And i doubt it is too hard to make/port for 1.2.x (I dont use 1.2.x though, so I dont know)

Here are the diff-reports for it (reports generated by 2 diffrent programs):
viewtopic.php: 1 2
post.php: 1 2