Personal Site Suggestions

[Kevin M]

Thanks justsomeguy, that was a great explaination. Well, database it is. I might experiment with flat file/XML file storage in the future, but not with this application.

[boen_robot]

What happens if you have an XML file with 1000 records in it and you need to delete record number 500 and upate record number 700?

That's exaclty why having tons of smaller XML files is better then having a few large ones.

Also how will you protect your xml files? If I know the path can I download it? I could take you user/password file and login into your blog as you.There are many reasons not to use XML, although I have considered the idea in hte past as a cross platform/hosting provider solution. In the end practicality won out and I used a database.

In the same topic which Kevin M refers to, me and Prateek went into some big discussion about this. He introduced an encyption method called "TEA" (Tiny Encryption Algoritm) which could encrypt a string and decrypt it with a predefined password. A similar technique applied over XML file would be the perfect solution. The password would be hardcoded in the S3L and will be adjustable (or randomly generated) on install. The file would be decrypted with that password on each request for it. This of course has a yet another performance penalty. But if you only encrypt data that needs to be encrypted, you'll increase efficiency a lot as there will be performance penalties only on login and registration (and perhaps email add/change if you collect that).For better security, one could also hide the file from HTTP clients with .htaccess file and the such, though if such is unavailable, ecnryption remains as a last resort. Placing the file outside the document root is best, but this is obviously not available in any host.Speaking of encryption, doing such would make the targeted XML lost the thing XML is best for - portability. Why? Because different S3Ls support different encryption methods (if any). One can always use a CLI in (almost?) any S3L, but that requires rights to execute programs, which wouldn't be granted in most hosts. Even so, the XML could always be decrypted when it has to migrate from one encryption method to another and encrypted later with the new one. MD5 could always be used to keep private data private for those short moments, though it would add yet another performance penalty at runtime (this particular one would be added with a DB too).

true parsing a small file compared to a large one would be faster but managing that many files would not be fun. Good Luck

True. That's probably the reason I haven't personally made such a CMS (even a basic one) to prove anyone wrong about all this.By the way, aren't databases also made to

facilitate the sharing of data across different information systems, particularly systems connected via the Internet

Only that they require a special software to run + a parser/language that can handle them. I mean, scince XML is a standart and written in plain text, it only requires the later.P.S. Damn it, I need to get some free time to finish the 3 small sites I've been tasked with and start making this cursed CMS. Thinking about it occupies to much of my burned mind already.

[justsomeguy]

That's exaclty why having tons of smaller XML files is better then having a few large ones.

If the choice is between a ton of small files or one database, I'll go with the database. I've done enough text processing to know what it is and is not good for, and storing large amounts of related data is not one of the things it's good for.As for the security and encryption thing, I'll just say that databases already take care of all of that. I don't need to worry about securing a database that doesn't accept remote connections in the first place.

By the way, aren't databases also made toQUOTEfacilitate the sharing of data across different information systems, particularly systems connected via the Internet

Databases were not built to share data, they were built to store it. Most of the databases I work with do not share anything, they don't even allow remote connections at all. They exist as a fast and efficient data store on a single machine.It's true that databases require more overhead to run then flat text files, which require no overhead at all. But getting data from a text file or updating it requires significantly more overhead then getting data from a database. Not to mention the fact that you can get a series of related records from different tables (or files) with a single statement on a database.

[PrateekSaxena]

TEA is great but I could not find something similar to it in PHP!

[PrateekSaxena]

http://media.rubyonrails.org/video/rails_t..._with_sound.mov see this if u hv time

[Kevin M]

Thanks Prateek, good video. I've heard of Ruby on Rails, but I had no idea what it was. I've had a look around their site. So is it a program to create good web applications in? Or is it something that you upload to your host, sort of like a Java Script library?Unrelated to the above paragraph, but I think this seems to be getting a bit too complicated for me. I know I said I wanted a challenge, and I do, but I don't even have that much database experience either. Thanks for all the suggestions and help on this guys, you are all really helpful with many different things. It's just that some of you have probably been programming and coding half as long as I've been alive (trust me, I'm probably younger than you may think.) and I just think while this may have been a possible solution for the application, it just doesn't seem probably with my stage in web development.Don't get me wrong, I really appreciate all of the helpful comments and suggestions, I just don't think that with my ability in programming that it would be a good idea for me. Maybe in a few years when I've developed as a developer (that was awkwardly phrased) I will consider making something similar to this, but not for a while.

[PrateekSaxena]

Try it out man. I wrote ParaTrooper when I was 11 or 12. Blake Ross would have worked on FireFox when he was 16. Sure you maybe younger but that does not mean that you cant to what Linus Trovalds or Bill Gates has done!http://w3schools.invisionzone.com/index.ph...ost&p=60288

[Kevin M]

I'll think about it. It's just that a database sounds so much more reliable, fast and even easier to use too. I'm sure I could figure out how to do it with XML, I just don't know. Gah, sometimes this all get's too complicated, lol. I'll think about it for a few days, and make my final decision. I'll have to look into some encryption methods, and some other stuff too. Wow though, you wrote ParaTrooper when you were 12, that's pretty good. What did you use, C++?

[PrateekSaxena]

yup! I did in C++If you are comfortable with the database...no one is forcing you to use XML..plus it is just a fun project not a project given to you by some company and stuff..

[Kevin M]

It's not that I'm more comfortable with it, it's just I don't want to decide to do it with XML/XSLT, then half-way through find out I made a bad decision, or vise-versa. I know no one's forcing me to do it one way or another, you're all just giving suggestions. I want to consider all of my options, and then decide what's best for me. Hopefully that way I won't make the mistake of choosing the wrong thing, and spending time doing something I'm not capible to do, if that makes sense.

[PrateekSaxena]

Alright...best of luck for whatever you choose!

[Kevin M]

Thanks man. You've been a big help.

[boen_robot]

It's not that I'm more comfortable with it, it's just I don't want to decide to do it with XML/XSLT, then half-way through find out I made a bad decision, or vise-versa. I know no one's forcing me to do it one way or another, you're all just giving suggestions. I want to consider all of my options, and then decide what's best for me. Hopefully that way I won't make the mistake of choosing the wrong thing, and spending time doing something I'm not capable to do, if that makes sense.

Unfortunately, you'll sooner or later find out the drawbacks of each method. The XSLT ones emerge pretty soon and are listed in this topic. The DB ones are also listed, but must be felt first hand to be understood. I mean, while XSLT places the constrain of "think very deep or face inefficiency and security risk", DBs place the constrain of "stay on this S3L, this DB or rewrite the whole application". Both are not exactly pleasant at the certain point.There's just no best method. But in the end of the day, you're happy with what is good enough for now and in the next few years which is a thing both methods can give if carefully thought.But no matter the choice, it will be tough since it will be your first application. But after all, that's what forums like this one are for. Resolutions to such issues.

[Kevin M]

Great post. You're right, I'm sure there's drawbacks to both methods. That's why I'm going to think about it for a few days. I've been looking through the XSLT tutorial at W3Schools (The XPoint one as well), and I think I've got a good grasp on the basics of it. It doesn't seen too hard to use, but I'm not thinking of anything complicated right now. I'm glad I've got a forum like this, with people that have way more knowledge than me. To me, a forum where you can ask questions and get answers from great people is better than any tutorial (to learn more than the basics). :)EDIT: Now that I've been thinking about it for a few minutes, I would only have to encrypt the files that had all of the username/password stuff right? (I think someone might have said that. I'm talking about XML right now). I could also give it a crazy file name like u1750se95.xml, which I know wouldn't be the best way to protect something, but it would only be a step of the protection. It's also better than having the file like uers.xml . I could also use .htaccess files to help as well (I think boen_robot said that earlier in the topic too). I'll still think though, just a few ideas that popped into my head that I didn't want to forget.

[PrateekSaxena]

I dont this that naming it u1750se95.xml will do any good regarding the security of the data present in it!

[Kevin M]

I realize that, I just figured having a harder name would make it harder to find. That wouldn't be the only thing I would do in terms of security though. It would just be one aspect of different things that I would do to protect the data in the select files. I'd also maybe change my password frequently, and have a hard password to guess. Along with other sexurity measures as well, like encrypting the select files.

[boen_robot]

EDIT: Now that I've been thinking about it for a few minutes, I would only have to encrypt the files that had all of the username/password stuff right? (I think someone might have said that. I'm talking about XML right now). I could also give it a crazy file name like u1750se95.xml, which I know wouldn't be the best way to protect something, but it would only be a step of the protection. It's also better than having the file like uers.xml . I could also use .htaccess files to help as well (I think boen_robot said that earlier in the topic too). I'll still think though, just a few ideas that popped into my head that I didn't want to forget.

Well, yes. I did said all of what you're saying, except the "crazy file name" thing, because that's not secure at all. If you distribute your project to the public, exploiters can always learn the naming convention and find what they need.Also, what I did not suggested was to keep secure data for each user separate, but then again, storing it in one file for each user, taking the file name as the user's ID might be good. Scince those XMLs are very performance critical, it's vital the nodes inside them are also reduced to a minimum. Like this:1.xml

<u p="Password as MD5 string"><m>email@adress.com</m></u>

("m" is an element, because you might want to allow people to add additional emails or other sorts of private information)Decrypting and parsing that shouldn't add that much performance penalty over the whole process (though it still would) and as we both said, it would only add such when it's needed to begin with, which means- when the user logins, when the user changes his password, when the user changes/adds an email. Acceptable I think, but as mentioned above, could start look ugly under the hood.This particular approach adds a barier, which wouldn't be with a DB or if the XML file was one. Scince each file has each user's email, it would be hard to implement a way to find whether the email was used already. I mean, in order to do that, all encrypted XML files would have to be decrypted and then each "m" element be compared to the input one... that even feels processor intensive now.Not to mention the problem with encryption itself. As Prateek already said, he couldn't find anything similar for PHP. I don't know about you, but I don't know any encryption method for PHP that would allow encryption and decryption on password. That is why it remains better to use a database at least for the secure data.I know I sound like I'm shifting away from my own position, but it's just that security is granted with a DB and portability is not. It's vise versa with XML and XSLT.Which brings me to another point which has been raised again and again in topics like this one, which is an approach I can agree on. An approach that gets you some of the benefits and some of the drawbacks of both methods, eliminating others of both. Of course, I mean use both methods.To be more precise, generate XML from a DB, and then transform that XML with XSLT. This unlocks XSLT's benefit of handling different user needs by being separated from the initial tree. For example, you can have one XSLT for XHTML, another for SVG, XSL-FO (for PDFs), WML, etc. This is of course also available with plain XMLs. This keeps the layout (XHTML) of the application portable as other S3Ls can always use this same XSLT. The thing you'll have to rewrite though would be the script that generates the XML file on the first place. This also applies for cases where you switch from one DB to another or from a newer uncompatable version of the same S3L.Infact, combining this approach with all of the above - taking only secure data from a database - would make your application almost completely portable. I mean, rewriting a script that would generate a small XML file like the above from a database shouldn't be much of a challenge.You must know that building an application that would utilize both methods to their limits would be a true challenge though. It's a hole form which you'll have a hard time escaping.

[Kevin M]

Guess the file name was a stupid idea, I have those a lot. Sounds like both would definately be a good method, but I agree using them to their best capacity would be a bit of a challenge. The thing is, in terms of users, I wasn't planning on the register option (at least in the first version). The only "registered" users would be the people making the updates/entries. This means that the file to encrypt/decrypt wouldn't get incerdible huge, and it wouldn't be too much of a hassle to do the encryption. It would still be possible to use both, maybe I will. That sounds like a good idea actually. Most of it would be XML/XSLT based, except for the user/log-in system then right? By using SQL not a specific database system like MySQL, would this make it easier to port to other S3Ls (That's a good acronym) since most of the different actions are similar?

[boen_robot]

By using SQL not a specific database system like MySQL, would this make it easier to port to other S3Ls (That's a good acronym) since most of the different actions are similar?

SQL is only the language that queries SQL based databases like MySQL. Think of it like the XPath of DBs. And each DB is dependant on it's engine/parser (in this case, MySQL). Also, SQL is not exactly a standart, so a certain SQL command might do different things in different DB engines, though it would mean the same for this engine, no matter the environment (S3L) in which that engine is used.How easy would be to port an application from MySQL to another database or another S3L depends very much on the API. I mean, is MySQL in ASP(.NET) used in the same way as in PHP? Do Oracle DBs have the same abilities like MySQL under PHP or ASP(.NET) for that matter? It's all connected. THAT is what makes DBs unportable.

[Kevin M]

Alright, I wasn't really sure. I could always just edit the database stuff to make the application available for S3Ls other than PHP (Which is probably what I'll start with), or even other database systems as well. I think I'll get a working version done with PHP and MySQL, and if that goes well, maybe make a version that uses ASP(.NET) as well.

[aspnetguy]

As much as I love ASP.Net, PHP/MySql gives you far more options on portability and hosting. Those options usually include saving money which I also love

[PrateekSaxena]

I would do it in PHP/MySQL too. The reason for that may also be that I don't know ASP~

[Kevin M]

I know a bit of basic syntax for ASP (Nothing in ASP.NET though), but probably not enough right now to even think about doing it with ASP. I much prefer PHP for some reason though, I don't know why.

[PrateekSaxena]

ASP is Microsoft right?

[Kevin M]

I'm pretty sure. So I don't think you can use it with Linux web hosting, which in most cases costs less than Windows hosting (I think that's what aspnetguy was talking about saving money above).