Abomination

Not today.

Hmm, but isn't this data stored in the database? So why would I attack the encrypted Nexus if the other apps are not encrypted? If I would like to steal your data I would attack at the weakest point. That's why I ask:

Lindy, on 02 November 2010 - 03:01 PM, said:

To me, as non-native-speaker this sounds like the "sensitive data" is also stored in databases. Lindy goes on and explains that those can be encrypted, which, I guess, means that it's not encrypted by default.

Sorry, I really love this software, but currently it looks a little unplanned and more like "we-do-as-we-feel" to me. I'm not quite sure if I should use Nexus for a future project I'm currently planning. Sure it would be great to have it directly tied to the forums, but... no, currently I'm just unsure.

michelle82, on 02 November 2010 - 02:46 PM, said:

If someone gets into your server it's game over. Nexus being encrypted wont help a bit here. IP.Board is unencrypted, it wouldn't be very hard for someone to write a hook or module that would interact with the system and grab the data.

Not to mention that if someone gets into your server he has the access details to your database aka all your data.

I am really disappointed with IPS dropping something like this on us on release day. I haven't the words.

I came here a bit late, so I'm wondering...was there any announcement at all made in the past that this product would be encoded? Any mention in a blog post or something? Just curious.

What security will we get with having these files encoded? I'm not following here. IP.Nexus is a COMPONENT in a bigger bundle of things. Should IP.Board be compromised you will have a problem since Nexus is just a module sitting on top of it. How does encoding JUST Nexus help here?

How extensible is the system now that everything is encoded? I doubt IPS is going to build in all the functionality a few people may require. Not having the option of hiring a developer to build in things makes Nexus a whole lot less appealing than it was before.

Why the lack of transparency? There should have been a blog post on this before release to bring attention to the fact it will be encoded. I've been planning on using this for my company for months now (and even delayed launching products specifically so we wouldn't have to switch just a couple months down the road) and now I'm left with a really bad taste in my mouth.

Disappointing.

I don't have an issue with that per-se. It's just the thoughtless "please add this Facebook feature" without considering how it will affect the forum. Much like suggesting we transplant eagle wings onto a family member because eagles can fly and flying is cool.

For the record, I don't think that a "like" feature is a bad idea. It's just that I want to fully consider how it fits in with our current reputation system. It would be wrong to throw out a feature on a whimsy.

bfarber, on 31 August 2010 - 10:56 AM, said:

Contrary to popular belief, there are power users who use View New Content and Today's Active Content as their primary links for new posts and threads. Since new reports and active posts from the report center are not included in "search", often times new items in the report center can go unnoticed. This has been one of my primary beefs with the report center and how it was implemented, and the biggest reason I and others have requested the option to send reported posts to a specific forum rather than that #$)(*&#$)(*& report center.

Oh I understood his comments perfectly. Yet, time and time again, some good suggestions seem to be discounted just because vB does it that way. I can understand some suggestions being rejected due to coding requirements, but it seems that many good suggestions are rejected just because "someone else" does it that way. That's a poor excuse for rejection, and one that is remembered for a very long time.

I'll add this for 3.2.

It's possible to do nearly anything with a modification.

Jυra, on 04 August 2010 - 07:19 PM, said:

This is the same exact attitude that kept me from participating at vbulletin.com forums for years. Apparently, there are people here that don't want to hear other peoples suggestions either. Maybe you don't mean to sound offensive...but that's how some of us will take it. And that's why you won't see others reply with their support or suggestions, too. They don't want your kind of responses on their opinions.

It would be different if you replied once. I already read that you don't support this idea. But, replying to anyone who supports the idea is a bit much and comes off offensive to some.

Just trying to explain my view...and going off the topic (ugh!) to do so....Sorry...maybe I should just keep quiet or look for other solutions elsewhere....or go back to using my vbulletin licenses.

glorify, on 04 August 2010 - 08:30 PM, said:

Thank you and have a splendid week*

I think Jaggi's joke went over a lot of heads

Collin1000, on 24 July 2010 - 03:25 PM, said:

They're different things. A single = is of course an assignment operator, a double (or triple) = is a comparison operator.

This is completely valid code:

if ( $foo = bar() )
{
	// Is executed if bar() returns true. $foo is now true.
}
else
{
	// Is executed if bar() returns false. $foo is now false.
}

On the other hand:

if ( $foo == bar() )
{
	// Is executed if bar() returns the same value as whatever $foo is
}
else
{
	// Is executed if bar() returns a different value as whatever $foo is
}

I think you may have some misconceptions about IP.Board's current architecture.

IP.Board uses completely object oriented programming, and is split into applications. The "forums" are simply an application which can be disabled. In fact, our website, invisionpower.com is running IP.Content with no forums attached (it is a separate installation, on a different server, to these company forums) - we simply turned off the forums and made IP.Content the default application - there is nothing special about this setup and can be done out of the box.
Applications make use of "extensions" which are standalone files that can be added and removed to applications. These enable things like attachments, notifications, reputation, etc. which are shared features. Our addon applications (IP.Blog, IP.Gallery, etc.) all use these shared features, yet there is no code in IP.Board at all that is specific to Blog or Gallery.

You can upgrade applications independently without affecting the others. We on these forums have IP.Board, all the applications and several "third party" apps (Tracker, Links) all of which have different development cycles and we upgrade independently.
If you have an application which breaks on a minor upgrade - that application is not making use of things like the hooks system, which it probably could to avoid this issue.


There are some things which textbook examples of modular applications would suggest which we deliberately don't do for technical reasons of a scalable and distributable application (for example, one might suggest one database table for posts, and comments in Blog, Gallery, Downloads, etc. but doing this you could easily hit some MySQL or OS limitations on tables/file sizes) but by and large, I'm confused as to what specifically you're suggesting we change... most of what you suggest is a description of what we already do.
The next major versions will definitely be 3.2, and then likely 3.3, etc - 4.0 is something we're not going to be thinking about any time soon.

Thanks guys made my decission bought it.

Abomination, on 23 July 2010 - 09:21 PM, said:

Ahhh another person has seen the light

Here is reason number 3 ... they listen to their customers