We *LOVE* the Session



  • At my current employer, our development team is fond of using the ASP.NET session for everything. And I do mean everything. While debugging an issue inside of a 2700+ line ASPX page (which is another WTF), inside of a 350 line button handler (which is yet another WTF), I noticed in the email log we have on every error that our Session variables list contains 43 items, including but not limited to several hundred lines of XML, two DataSets, one Hashtable and no less than three rich business objects.


  • Trolleybus Mechanic

    @ObiWayneKenobi said:

    At my current employer, our development team is fond of using the ASP.NET session for everything. And I do mean everything. While debugging an issue inside of a 2700+ line ASPX page (which is another WTF), inside of a 350 line button handler (which is yet another WTF), I noticed in the email log we have on every error that our Session variables list contains 43 items, including but not limited to several hundred lines of XML, two DataSets, one Hashtable and no less than three rich business objects.
     

    At least they aren't in a hidden field that's passed page-to-page via a cross-page postback.

    {weep}



  • @Lorne Kates said:

    @ObiWayneKenobi said:

    At my current employer, our development team is fond of using the ASP.NET session for everything. And I do mean everything. While debugging an issue inside of a 2700+ line ASPX page (which is another WTF), inside of a 350 line button handler (which is yet another WTF), I noticed in the email log we have on every error that our Session variables list contains 43 items, including but not limited to several hundred lines of XML, two DataSets, one Hashtable and no less than three rich business objects.
     

    At least they aren't in a hidden field that's passed page-to-page via a cross-page postback.

    {weep}

    Isn't that what ViewState is for?  Really, show me a single developer who wouldn't feel accomplished when you have IIS shittting out pages in the 500k size range?


  • @C-Octothorpe said:

    Isn't that what ViewState is for? Really, show me a single developer who wouldn't feel accomplished when you have IIS shittting out pages in the 500k size range?

    Depends upon the target audience. If for general users I'd try and keep it down from that for sure. It's not a diasaster for a complex application though aimed at users on an extranet. It's a compromise between using fancy grid type controls and spending the extra time to make it all spiffy - for an admin page I'll say just use the fancy dan controls and accept the ViewState hit, for a central data entry type page I'll try and be a bit more optimised.

    I'll always take the ViewState hit over Session though - it is occasionally necessary to use Session  but sparely and for integers alone ideally.



  • @callcopse said:

    @C-Octothorpe said:

    Isn't that what ViewState is for? Really, show me a single developer who wouldn't feel accomplished when you have IIS shittting out pages in the 500k size range?

    Depends upon the target audience. If for general users I'd try and keep it down from that for sure. It's not a diasaster for a complex application though aimed at users on an extranet. It's a compromise between using fancy grid type controls and spending the extra time to make it all spiffy - for an admin page I'll say just use the fancy dan controls and accept the ViewState hit, for a central data entry type page I'll try and be a bit more optimised.

    I'll always take the ViewState hit over Session though - it is occasionally necessary to use Session  but sparely and for integers alone ideally.

    Worst first past ever.  0/10.


  • Care to elaborate, orthographic fail hack?



  • @callcopse said:

    @C-Octothorpe said:

    Isn't that what ViewState is for? Really, show me a single developer who wouldn't feel accomplished when you have IIS shittting out pages in the 500k size range?

    Depends upon the target audience. If for general users I'd try and keep it down from that for sure. It's not a diasaster for a complex application though aimed at users on an extranet. It's a compromise between using fancy grid type controls and spending the extra time to make it all spiffy - for an admin page I'll say just use the fancy dan controls and accept the ViewState hit, for a central data entry type page I'll try and be a bit more optimised.

    I'll always take the ViewState hit over Session though - it is occasionally necessary to use Session but sparely and for integers alone ideally.

    Not sure if you're trolling, but I'll assume you're not.

    Firstly, ViewState and Session state serve two completely different purposes.  Comparing the two is like comparing a cars emergency brakes with their regular brakes.  Yes, you can argue that they kinda sorta achieve the same goal (stop the car), but they are implemented completely differently and are used for different purposes.  I would never use ViewState as a Session store, or attempt to hold view data in the session object.  If you're even considering that, you're doing it wrong...



  • @callcopse said:

    Care to elaborate, orthographic fail hack?
    I don't even know what this is supposed to mean.  I suppose that makes me an orthographic fail hack comprehension fail?

    But hey, let's take the entire page and cram it in the viewstate.  No need to worry about the client uploading 500KB/multiple MBs back to the server, right?  Everybody has a good connection, Shirley.



  • @callcopse said:

    Care to elaborate, orthographic fail hack?
    See my response.

    I don't mean to sound like a dickweed, but I've seen this too many times (view data in session object, tons of crap in session, huge viewstate objects, etc.).  Except for a few exceptions, you won't even need viewstate.  As someone on another thread has already shared, just turn off viewstate by default, and only enable where you need it.  It's a little more work, but you'll find that in most cases, everything will work as expected.



  • @Sutherlands said:

    comprehension fail?

    But hey, let's take the entire page and cram it in the viewstate.  No need to worry about the client uploading 500KB/multiple MBs back to the server, right?  Everybody has a good connection, Shirley.

    What I mean is - if you're liable to go in all attack dog on a shy little users first post you could at least spell properly. (Post <> Past).

    I'm not saying optimising page load is stupid, just that it is premature in some cases, and modern grids often do have a high impact on ViewState. Sometimes you might want to do something about that, other times who gives a flying one? (e.g. Only occasionally used by users logged in from business connections etc).

    I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.

    OK?



  • @callcopse said:

    What I mean is - if you're liable to go in all attack dog on a shy little users first post
    Fair enough, my bad.

    @callcopse said:

    you could at least spell properly. (Post <> Past).
    Whoops. Still didn't even see that.  Also, I saw "orthographic" and read it as "octothorpic"

    @callcopse said:

    I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.

    Why is a large ViewState ok, but a large Session is not?  I'm not much of a webdev, but it seems to me that ViewState gets sent over the wire with each request, and a session gets saved on the server?  If that's the case, it seems like (depending on load/memory) big session would allow it to perform a lot quicker than sending the info over the wire each time.


  • @Sutherlands said:

    @callcopse said:

    I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.

    Why is a large ViewState ok, but a large Session is not?  I'm not much of a webdev, but it seems to me that ViewState gets sent over the wire with each request, and a session gets saved on the server?  If that's the case, it seems like (depending on load/memory) big session would allow it to perform a lot quicker than sending the info over the wire each time.
    To be fair to callcopse, Session can be stored in a number of ways.  If it's in-process, then it's blazing fast and you're only limited by server memory.  Then there is state server, which IIRC is sent via binary serialization to another server, also a very fast method of session storage.  The other common one is SQL session state, which can be slow as it's a trip to the DB on the request, deserialize, [page lifecycle here], serialize and send back to DB, but scales well to a web farm.

    I'd also like to point out that callcopse *is* equating the two simply by saying he would rather have a large ViewState vs. large Session object.

    Either way, I'm curious as to why callcopse thinks Session is so much worse than ViewState.  Me thinks he read a single article proclaiming the virtues of ViewState over Session without performing any critical thinking after reading it.



  • @C-Octothorpe said:

    @Sutherlands said:

    @callcopse said:

    I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.

    Why is a large ViewState ok, but a large Session is not?  I'm not much of a webdev, but it seems to me that ViewState gets sent over the wire with each request, and a session gets saved on the server?  If that's the case, it seems like (depending on load/memory) big session would allow it to perform a lot quicker than sending the info over the wire each time.
    To be fair to callcopse, Session can be stored in a number of ways.  If it's in-process, then it's blazing fast and you're only limited by server memory.  Then there is state server, which IIRC is sent via binary serialization to another server, also a very fast method of session storage.  The other common one is SQL session state, which can be slow as it's a trip to the DB on the request, deserialize, [page lifecycle here], serialize and send back to DB, but scales well to a web farm.

    I'd also like to point out that callcopse *is* equating the two simply by saying he would rather have a large ViewState vs. large Session object.

    Either way, I'm curious as to why you think Session is so much worse than ViewState.  Me thinks you read a single article proclaiming the virtues of ViewState over Session without performing any critical thinking after reading it.

    Well, I am simply comparing the two evils, not saying one is used for the same purpose as the other, which you kind of implied as a bit of a sneaky dig. In-process session is not a great idea if there is any likelihood of app recycling - like there might not be on shonky old IIS. That leaves DB or Service State. I guess it is personal preference and shop working practice, and perhaps a hang over from classic ASP, days but leaving 'rich' stuff in DB session when you might just recreate seems rather pointless, and I prefer to avoid even a whiff of overwhelming State service. I don't 'prefer' large ViewState just sometimes don't think it the end of the world. Depending on usage.

    In terms of the 'recreate' above a rich object can be serialised / de-serialised from DB pretty simply, and it's a technique that is very effective - never missed a beat in doing that kind of thing (Usual provisos about updating object model etc)

    Are you making a case for loading session more heavily? Guess you might not have seen the fairly non-l33t servers we get to use...



  • @callcopse said:

    Well, I am simply comparing the two evils, not saying one is used for the same purpose as the other, which you kind of implied as a bit of a sneaky dig
    I was trying to defend and understand you, assuming that this was just a language barrier thing. I wasn't trying a sneaky dig, it's *how* you said it. Maybe you didn't mean to compare the two, but by saying you would prefer ViewState over Session state means that at a given point, you had a choice to use either ViewState or Session to store [object] in, and you would use ViewState.  So, indirectly, you compared the two.  If you said you're not, then fine, whatever.

    @callcopse said:

    days but leaving 'rich' stuff in DB session when you might just recreate seems rather pointless
    What the fuck are you talking about? You don't store your database information in session, and I never said you would or should.  You would, however, use it to store the users shopping cart, or preferences, etc.  Stuff that you can't get from the database.  And there is nothing wrong with SQL session state.  If you're in a farm where you have two or more load balanced web servers, then the only choice you have is either State server, or SQL session state (or custom, like a cache server).  I'm not sure why you're being a snooty prick about the different technologies/techniques. It only makes you sound uninformed and unwilling to learn.

    @callcopse said:

    In terms of the 'recreate' above a rich object can be serialised / de-serialised from DB pretty simply, and it's a technique that is very effective - never missed a beat in doing that kind of thing (Usual provisos about updating object model etc)
    Wha?

    @callcopse said:

    Are you making a case for loading session more heavily?
    No. Not sure where you got that.

    @callcopse said:

    Guess you might not have seen the fairly non-l33t servers we get to use...
    Are you trying to sound like a complete ass, or is this a language issue? I'm beginning to think that you're trying to sound like an agressive tard in hopes of scaring me off, and it might have worked if you weren't spewing complete and utter billshit.


  • Trolleybus Mechanic

    @C-Octothorpe said:

    Isn't that what ViewState is for?
     

    Not really. It's meant to have information survive a page postback, but not interpage navigation. The following is probably not 100% accruate and won't make you a MCP, but:

    1) Session => Keep shit in memory for the whole website. IE: Which user am I logged in as?

    2) ViewState => Keep shit alove for the page you're on. IE: Which post am I reading?

    3) Context.Items or Form => Move shit between pages. IE: Take this textbox and jam it into the Preview page.

    I have no problem keeping large datasets in the viewstate, as long as you've looked into Server Side Viewstate. If you haven't, google it. It's a few LoC in Global.Asax, and a couple classes, and BAM, every single page stops emitting hundreds of kilobytes of extronious security-breaches-waiting-to-happen.



  • @Lorne Kates said:

    @C-Octothorpe said:

    Isn't that what ViewState is for?
     

    Not really. It's meant to have information survive a page postback, but not interpage navigation. The following is probably not 100% accruate and won't make you a MCP, but:

    1) Session => Keep shit in memory for the whole website. IE: Which user am I logged in as?

    2) ViewState => Keep shit alove for the page you're on. IE: Which post am I reading?

    3) Context.Items or Form => Move shit between pages. IE: Take this textbox and jam it into the Preview page.

    I have no problem keeping large datasets in the viewstate, as long as you've looked into Server Side Viewstate. If you haven't, google it. It's a few LoC in Global.Asax, and a couple classes, and BAM, every single page stops emitting hundreds of kilobytes of extronious security-breaches-waiting-to-happen.

    I appreciate the clarification, but I was just joking.  Didn't you read the rest of my post?  It was right next to the part that you responded to...  :)

    EDIT: Yeah, I also did the viewstate provider for writing to the file system and a distributed cache server.


  • Trolleybus Mechanic

    @C-Octothorpe said:

    @Lorne Kates said:

    @C-Octothorpe said:

    Isn't that what ViewState is for?
     

    Not really.

    Didn't you read the rest of my post? 

     Not really. :|

     

     



  • @C-Octothorpe said:

    You don't store your database information in session, and I never said you would or should.  You would, however, use it to store the users shopping cart, or preferences, etc.  Stuff that you can't get from the database.

     

    Wait, what?  If those things don't come from the database, then where do they come from?  In particular, at least on the last shopping-cart site that I had any hand in, the contents of the cart needs to be retained if the user logs out / closes browser / crashes browser and then logs back in.  (You might use session to cache things that you're confident won't change.)

     

    I mostly use session to retain things like, if the user

    1. goes to Reports.aspx?EntityID=1
    2. switches from January 2012 to September 2011
    3. runs some reports
    4. goes to Reports.aspx?EntityID=2

    then that second page starts out with September 2011 selected, without having to screw around with appending &Month=9&Year=2011 to every single variation of #4 that the user could click.  (The reason #4 is a whole separate page from #1 is that about 80% of the page content is potentially different from one entity to another.)

     



  • @emurphy said:

    @C-Octothorpe said:

    You don't store your database information in session, and I never said you would or should.  You would, however, use it to store the users shopping cart, or preferences, etc.  Stuff that you can't get from the database.

     

    Wait, what?  If those things don't come from the database, then where do they come from?

    Um ... at a first guess ... the user?

    @emurphy said:

    ... the contents of the cart needs to be retained if the user logs out / closes browser / crashes browser and then logs back in.  (You might use session to cache things that you're confident won't change.)

    So in other words you don't store your database information in session, you store your session information in a database (not necessarily the same one that C-Octothorpe is talking about).

     

    I mostly use session to retain things like, if the user

    1. goes to Reports.aspx?EntityID=1
    2. switches from January 2012 to September 2011
    3. runs some reports
    4. goes to Reports.aspx?EntityID=2

    then that second page starts out with September 2011 selected, without having to screw around with appending &Month=9&Year=2011 to every single variation of #4 that the user could click.  (The reason #4 is a whole separate page from #1 is that about 80% of the page content is potentially different from one entity to another.)

    You mean you don't get that from the database?

    You might not agree on the precise details of how to implement the examples C-Octothorpe threw out as just that - but it sounds like you're saying substantively the same thing.

     



  • @Watson said:

    You might not agree on the precise details of how to implement the examples C-Octothorpe threw out as just that - but it sounds like you're saying substantively the same thing.

    It looks like they are:


    @emurphy said:

    Wait, what?  If those things don't come from the database, then where do they come from?

    @Watson said:

    Um ... at a first guess ... the user?

    Talking cross-purposes here: an enumerated list (products available) will be constructed from data held in the database; a user's particular choice of one from that list (cart ID) will be held in the session, and more products being added to the cart will possibly be stored in the database but using the user's data to identify the location of their choices.

    Most session-based systems try to store as much data server-side where possible and only store minimal information within the session (or client-side), enough to reference the correct pool of data on the server.

    I'm no ASPX programmer, but the original WTF here sounds like everything is stored in the session to be passed back and forth between server and client here. That correct?



  • @C-Octothorpe said:

    Are you trying to sound like a complete ass, ....

    I respectfully withdraw from this conversation - not sure why it went wrong but there you go.


  • Trolleybus Mechanic

    @Cassidy said:

    Most session-based systems try to store as much data server-side where possible and only store minimal information within the session (or client-side), enough to reference the correct pool of data on the server.

    Correct.


    I'm no ASPX programmer, but the original WTF here sounds like everything is stored in the session to be passed back and forth between server and client here. That correct?

     

    Nope, the OP's data was being stored server-side. But way too much data, and data that didn't need to live for the full session. To go to your example:

     @Cassidy said:

    Talking cross-purposes here: an enumerated list (products available) will be constructed from data held in the database; a user's particular choice of one from that list (cart ID) will be held in the session, and more products being added to the cart will possibly be stored in the database but using the user's data to identify the location of their choices.

    The OP's session held both the user's choice of items (shopping cart) *AND* the entire enumerated list of products.  That's a bad thing for several reasons:

    1) The list of products doesn't need to be available on every single page the user visits. Do they need a list of products when they go to the Change Password screen?

    2) The list of products is out of date in the session. If the list changes (add, edit, remove), quantity changes, etc, etc, then the user is working off an outdated list.

    3) This list of products is a large set of data. Each and every user of the system will take their own copy, and thus use up that much memory. If the data set is huge, and there's a large number of users, you now have a HugeLarge amount of memory being used.

    From the looks of it, the OP's session did this with not only Products, but also-- I don't know-- services, and locations, and... etc.

     



  • @Lorne Kates said:

    The OP's session held both the user's choice of items (shopping cart) *AND* the entire enumerated list of products.

     

    Am I the only one who thought of the Storray Engine at this point?




  • It's a shipping application so there are several screens that require the data from the initial quote, hence storing all of it in the session (e.g. you specify the dimensions of what you want to ship, then pick a rate, then enter information about where it's coming from/going to, then information about the items, etc.) so that each subsequent page in the workflow can access all of the details. What makes it even more WTF-y is that some things you can do actually force the shipment to be requoted, which repeats all of the logic that already was done and stores it BACK into the session. And usually THAT logic is copy/pasted.

    As a bonus WTF I'm working on redoing some pages in our ERP system that use popups because popups are wonky on the iPad and all the executives use iPads (no joke that is the reason for this change). I've found at least five classes right now that are almost exact copy/pastes of each other except for the name (often just for something like "ShipTo" versus "ShipFrom", so there is a class called ShipTo.cs that has the same exact code as ShipFrom.cs other than references to "to" being changed to "from") and the name of a stored procedure (of which we have about 1500).

    As an ADDITIONAL bonus WTF, a little over a year ago we decided we could make our internal ERP system sellable to other companies (i.e. SaaS). The solution for this was to add an "AccountID" parameter to everything, every single page, every single stored procedure. No other change was made; nothing in regards to server scalability or database scalability, just an ID. And this is supposed to be able to support dozens of concurrent users, when it can barely support our ~80 person company without having to be restarted almost every day due to memory/IIS issues.



  • @callcopse said:

    @C-Octothorpe said:

    Are you trying to sound like a complete ass, ....

    I respectfully withdraw from this conversation - not sure why it went wrong but there you go.

    Who are you and why are you here?



  • @serguey123 said:

    @callcopse said:

    @C-Octothorpe said:

    Are you trying to sound like a complete ass, ....

    I respectfully withdraw from this conversation - not sure why it went wrong but there you go.

    Who are you and why are you here?

    Please be polite with the new users.



  • @ObiWayneKenobi said:

    As a bonus WTF I'm working on redoing some pages in our ERP system that use popups because popups are wonky on the iPad and all the executives use iPads (no joke that is the reason for this change).

    Similar situation: peculiarly, our company's website was actually an Internet-Explorer site (coded to IE5/6 standards) so didn't render or work properly in other browsers, but the marketing manager pointed out to me that most visitors to our site were IE users.

    I responded that anyone not using IE would never be our customer since they wouldn't be able to view or order our products. However, most people use Windows, and Windows comes with IE, so those furry-tooth Loonix geeks with their niche browsers will have to get into the real world and use a proper OS/browser like everyone else does.

    Then many education establishments began to use Opera. And we lost a few customers in the design industry that use a Mac. And along came mobile computing. And the iPhone, and the iPad, and... suddenly our site working in nothing but IE[1] became a major customer-shedding problem.

    [1] IE6, that was. It semi-worked in IE7, so it even contained version-specific HTML.



  • @morbiuswilters said:

    @serguey123 said:

    @callcopse said:

    @C-Octothorpe said:

    Are you trying to sound like a complete ass, ....

    I respectfully withdraw from this conversation - not sure why it went wrong but there you go.

    Who are you and why are you here?

    Please be polite with the new users.

    Who are you and what have you done to morbs?

    @callcopse: Congrats on joining, I recommend you run while you have your sanity welcome you with open arms to this fora.  Hope you enjoy the dead cats that dhromed will let at your doorstep or the bloody cat stool left by morbs at your carpet the warm feelings of belonging to this great community



  • @morbiuswilters said:

    @serguey123 said:

    @callcopse said:

    @C-Octothorpe said:

    Are you trying to sound like a complete ass, ....

    I respectfully withdraw from this conversation - not sure why it went wrong but there you go.

    Who are you and why are you here?

    Please be polite with the new users.
    Agreed.  Next time we'll say "please" before we gang rape the little prick welcome him to our, uh, welcoming community...


  • @serguey123 said:

    @morbiuswilters said:

    @serguey123 said:

    @callcopse said:

    @C-Octothorpe said:

    Are you trying to sound like a complete ass, ....

    I respectfully withdraw from this conversation - not sure why it went wrong but there you go.

    Who are you and why are you here?

    Please be polite with the new users.

    Who are you and what have you done to morbs?

    @callcopse: Congrats on joining, I recommend you run while you have your sanity welcome you with open arms to this fora.  Hope you enjoy the dead cats that dhromed will let at your doorstep or the bloody cat stool left by morbs at your carpet the warm feelings of belonging to this great community

    One of the forum rules is that we go easier on new members. Some people don't expect our rough-and-tumble environment and can be scared off by the insults, etc.



  • @morbiuswilters said:

    One of the forum rules is that we go easier on new members. Some people don't expect our rough-and-tumble environment and can be scared off by the insults, etc.

    I must have missed that meeting, (it seems I was not the only one).

    However how do you construe my post as either insulting or rough as per this fora standard?

    @serguey123 said:

      

    Who are you and why are you here?

    I was merely amazed

    Besides most people lurk for a while before deciding to join (I did) and in the general state of the internet (cesspool) it would be shocking if people expected otherwise

    Anyways, new guy if I insulted you, I apologize



  • @serguey123 said:

    I must have missed that meeting, (it seems I was not the only one).

    It was a long time ago, but it was one of the things Alex was concerned about.

    @serguey123 said:

    However how do you construe my post as either insulting or rough as per this fora standard?

    My comment was directed at you and C-Octothorpe. It's no biggie, just try to keep in mind that newbies should be treated a little less harshly.



  • @morbiuswilters said:

    @serguey123 said:
    However how do you construe my post as either insulting or rough as per this fora standard?
    My comment was directed at you and C-Octothorpe. It's no biggie, just try to keep in mind that newbies should be treated a little less harshly.
    He started it...



  • @morbiuswilters said:

    One of the forum rules is that we go easier on new members. Some people don't expect our rough-and-tumble environment and can be scared off by the insults, etc.
     

    I subscribe to this notion, obviously. New users might not realize it's style, not content.

    Bbut really, it's not a rule if it's not written and agreed upon, is it? More like a local guideline, I suppose.

     

    Now fetch the lube. I have work to do.



  • @dhromed said:

    Now fetch the lube. I have work to do.
    Looking at your avatar while reading this line made me shoot coffee out of my nose.



  • @dhromed said:

    Bbut really, it's not a rule if it's not written and agreed upon, is it? More like a local guideline, I suppose.

    When have we ever had written forum rules? But, seriously, Alex almost banned me once for flaming newbies. And when I was leading the Revolt Against the Moderators, it was agreed that we would tolerate most behavior, so long as new users weren't scared off from the forums.



  • @morbiuswilters said:

    When have we ever had written forum rules?
     

    Well, never. I've thought about maybe writing a few loose "recommendations" but it came no further than a thought, because we don't have to control teenagers and/or controversial lunatics.

    @morbiuswilters said:

    But, seriously, Alex almost banned me once for flaming newbies.

    Cool story bro. Never knew.

    @morbiuswilters said:

    it was agreed that we would tolerate most behavior, so long as new users weren't scared off from the forums.

    Somehow the event of this agreement is not among my memories. That is to say, yes of course I agree.

    Maybe I was drunk?

     

     



  • @C-Octothorpe said:

    @dhromed said:

    Now fetch the lube. I have work to do.
    Looking at your avatar while reading this line made me shoot coffee out of my nose.

     

    Maybe we could have a rule where TDWTF cannot be held liable for destroyed hardware as a result of gratuitous liquid application.

     



  • @morbiuswilters said:

    when I was leading the Revolt Against the Moderators
     

    I should be making some high-brow political superjoke about this, cherry-picking the relationships and career paths of several well-known revolutionaries into a giant pastiche-wad, thus illustrating my prowess as an indupitable Witmaster, but I can't think of anything so you get to look at my icon again.


  • ♿ (Parody)

    @dhromed said:

    Maybe we could have a rule where TDWTF cannot be held liable for destroyed hardware as a result of gratuitous liquid application.

    That certainly sounds sufficiently vague for this crowd.



  • @boomzilla said:

    @dhromed said:
    Maybe we could have a rule where TDWTF cannot be held liable for destroyed hardware as a result of gratuitous liquid application.
    That certainly sounds sufficiently vague for this crowd.
    There is no mention as to the viscosity of this liquid he speaks of...  These are important details!



  • @C-Octothorpe said:

    @boomzilla said:

    @dhromed said:
    Maybe we could have a rule where TDWTF cannot be held liable for destroyed hardware as a result of gratuitous liquid application.
    That certainly sounds sufficiently vague for this crowd.
    There is no mention as to the viscosity of this liquid he speaks of...  These are important details!

    Come on man, I know that dhromed new avatar is sexy and all, but there are limits!



  •  We should create lolpics and ragecomics featuring my avatar as the new Trollface 2.0



  • @dhromed said:

     We should create lolpics and ragecomics featuring my avatar as the new Trollface 2.0

    Stop trying to get people to love your new avatar. It's not working.



  • @morbiuswilters said:

    @dhromed said:

     We should create lolpics and ragecomics featuring my avatar as the new Trollface 2.0

    Stop trying to get people to love your new avatar. It's not working.

     

    I want a divorce.

     



  • @dhromed said:

    @morbiuswilters said:

    @dhromed said:

     We should create lolpics and ragecomics featuring my avatar as the new Trollface 2.0

    Stop trying to get people to love your new avatar. It's not working.

     

    I want a divorce.

     

    I want a series of pleasurable--but ultimately unsatisfying--affairs, ending with reconciliation and growing old together.



  • @morbiuswilters said:

    I want a series of pleasurable--but ultimately unsatisfying--affairs, ending with reconciliation and growing old together.
     

    Do dead bodies grow old?



  • @dhromed said:

    @morbiuswilters said:

    I want a series of pleasurable--but ultimately unsatisfying--affairs, ending with reconciliation and growing old together.
     

    Do dead bodies grow old?

     

    No, but they do bloom into new life.

     



  • @dhromed said:

    @morbiuswilters said:

    I want a series of pleasurable--but ultimately unsatisfying--affairs, ending with reconciliation and growing old together.
     

    Do dead bodies grow old?

    Nope, they grow mold ;)

    PS: Only in the proper environment, also some parts do continue to grow for a while like nails and hair


  • Discourse touched me in a no-no place

    @serguey123 said:

    also some parts do continue to grow for a while like nails and hair
    No they don't. It's the surrounding tissue that shrinks due to dehydration that gives the impression they do.


Log in to reply