Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
3376
Features / Re : Rewriting the skin file parser...
« on May 20th, 2012, 03:21 PM »
That's the thing, I'd be interested in testing it on a Linux server because IIRC Windows doesn't have the same concepts of caching at the OS level that Linux does.
3377
Features / Re: Aeme features ideas.
« on May 20th, 2012, 03:18 PM »
If you move the poster_time into the topics table, you have to do it for both the first and last posts in the topic, and you have to remember to update these when posting, but since you're already doing that to set up the first/last post id that's no biggie. (But we need to keep those too.)
You could only really benefit in moving if you can avoid the join to the messages table in the process, and that's already done in some places anyway. But I'm not a fan of moving the subject there.
While I couldn't care less about the subject being settable per post (and I have used it very sparingly), I do care about the performance impact that will have, as I observed with SimpleDesk; the topics table is fixed width, means it's *very* fast to traverse and look up, especially when you get into the realms of sorting. If you pull non-fixed-width content into that, it starts to hurt, and bear in mind there are several places that makes a difference (message index, display for the topic and prev/next for the topic come to mind)Quote Yes - but also, that *all* becomes searchable, for free. I consider that a bonus.
You could only really benefit in moving if you can avoid the join to the messages table in the process, and that's already done in some places anyway. But I'm not a fan of moving the subject there.
While I couldn't care less about the subject being settable per post (and I have used it very sparingly), I do care about the performance impact that will have, as I observed with SimpleDesk; the topics table is fixed width, means it's *very* fast to traverse and look up, especially when you get into the realms of sorting. If you pull non-fixed-width content into that, it starts to hurt, and bear in mind there are several places that makes a difference (message index, display for the topic and prev/next for the topic come to mind)
I don't mind using entire boards for an album. I just hope you realize that it'll make the topic table grow way more quickly than if we stored one album per topic
3378
Features / Re: Aeme features ideas.
« on May 20th, 2012, 12:15 AM »
Well, here's the thing. There's ordering topics by time/date and ordering posts by time/date, the latter certainly would likely be able to be indexed and the query for identifying posts based on that should be comparable with the current query (since the message ids can be found from the index), and requires no changes anywhere to queries other than to change the field we're pointing at.
Now, in the message index, the primary methods of sorting are by first post or last post in a thread (barring sticky), and though there are others, in virtually every case we'll be using those. The problem is that that those fields are not part of the topics table, and that means an extra join that we might need to work into the mix, or juggle the existing (complicated) joins. (And we need to apply this to the join made for the previous/next topics too)
The bottom line is that it will have a performance impact spread across more places - unless we keep the first post's and last post's time in the topics table too (and have an index on there too)
The reason I stepped back on the whole floating-topics idea is because of the debate we had before about having non-contiguous ids, e.g. board 1 is a default board, board 3 is the first user created board, and board 2 can't be used by default by the user - something similar will happen here.
I'd rather make an album as a type of board, because what we're talking about is a container that contains one or more content items - which means making the album's comments into a sticky topic. It does make some of the management complicated, but we can suitably manage that.
Now, in the message index, the primary methods of sorting are by first post or last post in a thread (barring sticky), and though there are others, in virtually every case we'll be using those. The problem is that that those fields are not part of the topics table, and that means an extra join that we might need to work into the mix, or juggle the existing (complicated) joins. (And we need to apply this to the join made for the previous/next topics too)
The bottom line is that it will have a performance impact spread across more places - unless we keep the first post's and last post's time in the topics table too (and have an index on there too)
The reason I stepped back on the whole floating-topics idea is because of the debate we had before about having non-contiguous ids, e.g. board 1 is a default board, board 3 is the first user created board, and board 2 can't be used by default by the user - something similar will happen here.
I'd rather make an album as a type of board, because what we're talking about is a container that contains one or more content items - which means making the album's comments into a sticky topic. It does make some of the management complicated, but we can suitably manage that.
3379
Features / Re: Aeme features ideas.
« on May 19th, 2012, 11:35 PM »
I don't know... there are serious benefits to ordering by physical id but note that I'm not talking about the same thing that you are.
If you filter by id_board + some kind of filter (which I'd make a dual index), you can still sort by id_topic which can be regularly increasing. But it does, as you say, cause trouble for importing just as it can for merging/external importing stuff.
In an ideal world, I'd just sort by time and be done with it but the performance aspects are awkward - InnoDB physically arranges rows by primary key as opposed to MyISAM ordering by creation and where it'll fit in the table - but I don't think we can do much about changing it, I think we're going to have to swallow the penalty of ordering by time, or we don't do this using the boards/topics tables.
If you filter by id_board + some kind of filter (which I'd make a dual index), you can still sort by id_topic which can be regularly increasing. But it does, as you say, cause trouble for importing just as it can for merging/external importing stuff.
In an ideal world, I'd just sort by time and be done with it but the performance aspects are awkward - InnoDB physically arranges rows by primary key as opposed to MyISAM ordering by creation and where it'll fit in the table - but I don't think we can do much about changing it, I think we're going to have to swallow the penalty of ordering by time, or we don't do this using the boards/topics tables.
3380
Features / Re: Aeme features ideas.
« on May 19th, 2012, 08:41 PM »
Hmm, yeah, there are benefits to sorting by id, too :/
3381
Features / Re: Aeme features ideas.
« on May 19th, 2012, 08:31 PM »
Let me put it this way, I read your description several times and I was still left confused as to how to query it.
Why would you have to have the board type in the URL? See, I'm thinking about the last time we talked about this, where you wanted to have things so that board 2 was the second real board and that the recycle bin was somewhere else - the same core problem is applicable here.
In the way I'd see it, an album is an entry in the boards table, then a media item just exists as a new 'topic'. Thus you lose the continuity of ids but you don't lose any ids, per se.
Why would you have to have the board type in the URL? See, I'm thinking about the last time we talked about this, where you wanted to have things so that board 2 was the second real board and that the recycle bin was somewhere else - the same core problem is applicable here.
In the way I'd see it, an album is an entry in the boards table, then a media item just exists as a new 'topic'. Thus you lose the continuity of ids but you don't lose any ids, per se.
3383
Features / Re: Aeme features ideas.
« on May 19th, 2012, 06:02 PM »
I'd rather break auto incrementation than make the system convoluted, personally. Auto incrementation does not bother me in the scheme of things, making it harder to use, harder to support and harder to extend does bother me a lot though.
(FWIW, it doesn't even bother me that board 2 is currently the recycle bin by default)
(FWIW, it doesn't even bother me that board 2 is currently the recycle bin by default)
3384
I'm using Ubuntu server, no GUI (doing it all via WinSCP and PuTTY), but you get a choice of distros to play with.
Referral code is c06bda2f5288f410e1afc05cdfd4046616eae8fc thanks :)
I should also note that Linode does have multiple DCs across the world to work with, so I have my main Linode in Dallas and I have a secondary one for specific purposes in London.
Referral code is c06bda2f5288f410e1afc05cdfd4046616eae8fc thanks :)
I should also note that Linode does have multiple DCs across the world to work with, so I have my main Linode in Dallas and I have a secondary one for specific purposes in London.
3385
They do, but it's on top of the normal price of the VPS; 512 plan is an extra $5/month, 768 plan is extra $7.50 and 1024 is extra $10 per month. http://www.linode.com/backups/ has their backup setup, you might find it's better to roll your own setup rather than paying for theirs, but it's up to you.
3386
Linode has 3 plans that suit you then. It doesn't do 'burstable' RAM, it's all guaranteed resources.
512 Plan: 512MB RAM, 20GB storage, 200GB bandwidth/month, $19.95/month
768 Plan: 768MB RAM, 30GB storage, 300GB bandwidth/month, $29.95/month
1024 Plan: 1024MB RAM, 40GB storage, 400GB bandwidth/month, $39.95/month
I have the 1024 plan, but fun fact: 6 years ago when I took the plan out, it was a 160MB VPS for the same price - and all the upgrades to my plan have simply been by them, for free, over the time since then. Support is also fantastic, I've only had to contact them once, but that was after I screwed up my VPS to the point where it wouldn't boot, and they fixed it for me very quickly.
You get SSH out of the box but it wouldn't be hard to drop in your own GUI to manage (Webmin, for example)
512 Plan: 512MB RAM, 20GB storage, 200GB bandwidth/month, $19.95/month
768 Plan: 768MB RAM, 30GB storage, 300GB bandwidth/month, $29.95/month
1024 Plan: 1024MB RAM, 40GB storage, 400GB bandwidth/month, $39.95/month
I have the 1024 plan, but fun fact: 6 years ago when I took the plan out, it was a 160MB VPS for the same price - and all the upgrades to my plan have simply been by them, for free, over the time since then. Support is also fantastic, I've only had to contact them once, but that was after I screwed up my VPS to the point where it wouldn't boot, and they fixed it for me very quickly.
You get SSH out of the box but it wouldn't be hard to drop in your own GUI to manage (Webmin, for example)
3387
Features / Re: Aeme features ideas.
« on May 19th, 2012, 03:44 PM »
You see, now you've given me a specific example of use, I can actually understand the point of it.
Part of the problem with FB is that you actually can't always tell if you're commenting on the album or a picture in it (and half the time it seems to conflate the two for you anyway)
I have to say I'm not entirely sure how much use comments on an album might be at this stage but it's certainly an interesting idea.
Part of the problem with FB is that you actually can't always tell if you're commenting on the album or a picture in it (and half the time it seems to conflate the two for you anyway)
I have to say I'm not entirely sure how much use comments on an album might be at this stage but it's certainly an interesting idea.
3388
Well, I'd normally recommend Linode but it doesn't come with cPanel out of the box. You certainly can add cPanel to it but I find that it's about as easy to configure by hand (and you can then do things you wouldn't normally be able to do in cPanel)
Linode also has a range of plans, but I'm not sure what sort of specs you're looking for, but note that cPanel is licensed per server and weighs in at $450 or so a year for that server - so any host offering it is likely to be reasonably expensive.
Linode also has a range of plans, but I'm not sure what sort of specs you're looking for, but note that cPanel is licensed per server and weighs in at $450 or so a year for that server - so any host offering it is likely to be reasonably expensive.
3389
Features / Re: Aeme features.
« on May 19th, 2012, 05:00 AM »Well, you upload a bunch of "party photos" from last night, let's say 40 (random number) photos, you know a lot of these photos will share a lot of tags. If these items can inherit tags from its album, you can refine and edit the necessary tags for each photo, it would be nice.
Please listen to me at this point, it's important. What you've posted sounds like you're trying to give me a general example. I need specific use cases. Trying to argue that a feature should be implemented through a contrived example does not ever work.
Give me an *example* that you've actually come across where it would have helped, since that's what I asked for, not a contrived and semi-made-up example.
Re playlist, I have never tried it, no idea how it's supposed to work.
3390
Features / Re: Aeme features.
« on May 19th, 2012, 01:14 AM »
Why would you give comments to an album, out of interest?
I can see the logic of album-level default tags but I'm not sure it would be that useful. (FWIW, I don't recall it ever being asked for before)
What would you use these things for? (I'm not interested in how hypothetically these might be useful to the community at least, I'm interested in how, assuming you had the facility, how exactly you would use them. How you intend to use a feature specifically is a different thing to explaining its benefit generically. ;))
I can see the logic of album-level default tags but I'm not sure it would be that useful. (FWIW, I don't recall it ever being asked for before)
What would you use these things for? (I'm not interested in how hypothetically these might be useful to the community at least, I'm interested in how, assuming you had the facility, how exactly you would use them. How you intend to use a feature specifically is a different thing to explaining its benefit generically. ;))