Stories
Slash Boxes
Comments

SoylentNews is people

Lowering Bandwidth Costs for Slash-based Sites

posted by janrinok on Wednesday March 12 2014, @11:33PM   Printer-friendly
from the I-was-doing-OK-until-it-mentioned-perl dept.

xyzzyyzzyx writes:

"Avantslash is touting a user hosted perl script that, if paired with any web browser with JavaScript, promises to shave crucial bytes off of the standard Slash-based experience, one of which is our very own SoylentNews. Audiences include those with very limited bandwidth, such as those in developing countries with only 2G mobile access or dialup."

 
This discussion has been archived. No new comments can be posted.
Lowering Bandwidth Costs for Slash-based Sites | Log In/Create an Account | Top | 58 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 5, Informative) by hankwang on Thursday March 13 2014, @12:17AM

    by hankwang (100) on Thursday March 13 2014, @12:17AM (#15628) Homepage

    "Why not just merge this into the main Slashcode?"

    Developer here. Although it's perl, I'm afraid that trying to integrate it with slash is doomed. It won't scale with the kind of load on SN or /. . And frankly, parsing html code with tens of regular expressions is not what you'd do if it runs on the same server as SN. (wouldn't do it anyway if I had to write it from scratch today, but this is how it evolved over 10 years, and it does the job)

    But the UI and lightweight html could serve as inspiration for a mobile engine for SN.

    Starting Score:    1  point
    Moderation   +4  
       Interesting=2, Informative=2, Total=4
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   5  

  • (Score: 2, Interesting) by goodie on Thursday March 13 2014, @01:52AM

    by goodie (1877) on Thursday March 13 2014, @01:52AM (#15650) Journal

    THIS! I think that if this proves as good as it seems (can't wait to try it on my iphone during my commute tomorrow) we should find a way to "integrate" it with the SN codebase. After all what you do (if I understand it well) is reformat the info to fit a mobile device. There's no reason that we can't do that straight from the SN source without having to resort to the technique you guys have to use (which is normal on your side of the fence). Heck, in the future, we could have a simple cookie storing the mobile or desktop version of the site for viewing and redirect/pick a css based on that. I don't know if it just changes the look or involves different data as well for example.

    But I do read SN a lot on my iphone when I wait for appointments, meetings, etc. so it would be great to have this integrated into the SN codebase I think. Plus we may find that there is a lot more demand than we though for something like this if we can track the pages served by this "module"/functionality.

    And dammit I'm out mod points :/. But this is neat guys!

    • (Score: 4, Informative) by hankwang on Thursday March 13 2014, @07:27AM

      by hankwang (100) on Thursday March 13 2014, @07:27AM (#15752) Homepage

      "There's no reason that we can't do that straight from the SN source"

      Apparently, slashcode is rather convoluted. I think Mattie.p stated that it is difficult to implement skinning. I had a look at slashcode and it seems that there are many, many layers between parsing the cgi parameters and generating output. I couldn't figure out the code path from grepping the code. It looks like making a truly mobile layout, not just applying different css, requires changes all over the code base.

      I suspect that slashdot dragging their feet all those years with a mobile version has to do with the difficulty of implementing it. And that was with the original author, CmdrTaco/Rob Malda, on the team.

      • (Score: 1) by goodie on Thursday March 13 2014, @12:58PM

        by goodie (1877) on Thursday March 13 2014, @12:58PM (#15833) Journal

        I see... Maybe there is a way for SN to set up something on the side that consumes the data and skins separately from the main code while the mobile version only allows reading articles and comments? I admit that i have never looked at the SN codebase so if is all Perl from the late 90's it may not really have an api that we can call so to speak...

        Hey if we move toward a complete rewrite maybe this could be a good starting point to slowly build the new code up...