Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
It is really nice move. It will very helpful. The best feature is short tag which is very easy to use. At database side, there is something new in format. Overall, it is the best work and it is effective and reliable for use.
Sorry, I've been away for the week for a number of reasons.
The PHP patch should be pretty helpful! Getting rid of the short tags isn't hard, but it's a lot of grunt work. I think the last time I tried to do a search/replace, it messed up all the HERE DOCUMENTS code blocks. I just kept the short tags because, well, it's convenient.
Wacintaki 1.5.0 is in the works and solves the biggest PHP 6 issues: the database layer (MySQLi), and the use of "eregi". I'm also working on reworking the language files, so there will be fewer variables used, and that should cut down the number of PHP tags being used in the first place. The database config file has also finally been updated to a new format, so short tags have been removed from all the config files. I don't think PHP 6 will pose a problem.
Hello,
I already sent this via email to Waccoon, but maybe this is a better place since I got no answer to my mail.
It's a patch eliminating the use of short open tags, created and tested against the current stable version 1.4.3.
Sorry but there's no attachment support: http://nopaste.com/p/aiXGmRifs
I hope you're right that it won't be that big a switch. Part of me feels that they should definitely keep v6 backwards-compatible, but at the same time part of me wants to force change just to see the technology continue to progress. Oh well!
I'm sure you're right about the short tags sticking around with the change of a value in the configuration. If they up and disappeared, I'd bet close to 50% of PHP projects out there would cease to function properly. The ASP style tag will finally be gone though <% %> ... and finally stop breaking my code
Proper DBA would be amazing. It's unfortunate that PEAR isn't widely available... and even when it is, it's often much slower than, say, just using MySQL functions. Writing an abstraction layer yourself is becoming a popular choice, but I've attempted it and it just takes way too much time, and I'm not even sure there are benefits to it.... besides the fact that you probably don't need to rely on PEAR.
OOP in PHP is actually.... not that bad. I think it often gets a bad reputation for not being written nicely because of the backwards-compatibility factor. You can throw together a Class and some functions and call it OO programming, but if you take the time to write it well, it turns out just as nice as Java or C++ these days. As for namespaces... I heard that PHP6 might not even go there yet.
Now the ereg is interesting... I've always been using preg functions for a while simply because I heard they were faster. The regex is actually fairly different and it took me quite a long time to convert some of my older ereg code. What a pain! There ARE sites out there that help convert between the two, but even then it's completely unreliable and you're stuck having to learn it anyway.
In the end though, you're right... not a large or scary move to PHP6. It's mostly a maintenance release more than anything.
You're also right about the challenges keeping something like that going would be. It definitely couldn't compete with larger social sites of today, and would probably work better as an app for some larger project... forum integration and the like..
As for applets available, I wonder if the one Marcello was writing (Lascaux) would be a better start.. or.. some other kind of paint chat application. There really isn't anything available anymore, and to me this is a big shame.
Perhaps you're right.. I saw how BlueJot was coming along, and it's interesting he's wanting to use the Symfony framework in order to write it, but... yeah.. probably not going anywhere fast.
Yeah, it's still in the works, though I haven't been very active with updating things. I have other projects these days. I have no problem updating the code to fix major issues, but new features and a complete rewrite isn't looking realistic.
The good news is, PHP6 isn't that big a deal. Ereg is the only headache.
1) Short tags - From what I hear, they will work in PHP6 just like PHP5. But, that depends on the server configuration, not PHP itself. A rewrite of Wacintaki would revolve around templates, where PHP tags would be largely unnecessary. I've spent most of my coding time looking at slim template engines.
2) MySQLi - Ideally, a proper database layer should be used. I'm just not happy with the phenomenal amounts of bloat that comes with most database/template frameworks. It doesn't help that many such layers also rely on PEAR, which isn't available on most shared hosting plans. Frankly, database abstraction in PHP is pretty much broken to non-existent. Why they still shackle people to MySQL instead of going to proper database abstraction (like Perl) is beyond me. The good news is, PHP6 fully supports the old MySQL functions. The PHP team just recommends using the newer standard because it has more features.
3) OOP - To be honest, I don't know much about object programming and namespaces, though I do understand why they are a good idea (if a bit trendy). PHP doesn't do it very well, though. I have yet to look into OO differences between PHP5 and PHP6.
4) "Magic" thingies - Yes, those have been fully removed from the code, so no worries. I added the "w_gpc()" function to help clean input while still adding the slashes that OP really wants. That's hardly ideal, but it works. "Magic" quotes are most definitely gone, though.
5) Prepared statements - This is a big plus when working with UIDs rather than usernames. Unfortunately, the whole database has to be redesigned to use UIDs and UTF-8, so prepared statements are the least of my concerns.
6) ereg - Yes, NiftyToo is all done with ereg. This is a top priority. Unfortunately, I suck at regular expressions. Most of my attempts at fixing the code have resulted in "gotchas", and I can't just copy/paste GPL'd code into the project.
-----
There are effectively a few problems with Wacintaki which make a rewrite difficult:
1) License - I just can't write all the code myself, so making the board an official FOSS project so I can get good, tested code would be a big help. A complete rewrite from the ground up is required for this, and that's just too much for me to handle at the moment. Also, I'm an MIT/BSD guy. Most projects are GPL, and GPL doesn't play nice with anyone but GPL.
2) Normalizing the database is a big challenge. The update tool alone would be a major time siphon.
3) Dwindling Java support - Sun just doesn't care about applets, anymore. Java is all about server pages these days, and running on dedicated corporate servers to boot. Every time a new version of the JRE is released, things break like crazy, particularly with regards to applet signing and security exceptions, which cannot be resolved when dealing with shared hosts. Graphics problems are persistent, too, even with the DirectDraw and Direct3D fixes. With this in mind, it may not be possible to rely on the old Shi-chan applets, anymore. If there's no applets, there's no reason to rewrite Wacintaki. It doesn't help that Apple is apparently trying to kill Java by providing their own horribly crippled and buggy version of the JRE with OSX, and they are also legally barring Sun from releasing a version of Java that actually works. Every time I try to refactor the applets, Mac support is totally broken. That pisses me off. I've seen paint programs written in Flex (aka Flash), such as Sumopaint, but there's nothing available as a FOSS project as far as I know. If there's no applets, there's no oekaki. Period.
4) Social web sites like DA/SA/FA, and retard magnets like chan' boards, have all pretty much killed oekaki. Lots of people are still registered on oekaki boards, but not many people participate, anymore. I am not interested in turning Wacintaki into a social framework, because I feel that misses the point completely. Turning the board into a framework that can be integrated easily into forums, CMSes, and social networks would be a good idea. Making oekaki more sophisticated and flooding it with cross-linking, fav, and friend features would just be a nightmare. I don't want to get involved with that crap. I want oekaki to be simple and fun, and have it run on any web site whether it's a dedicated host or a shared Linux box. I just don't know how to do that and still make the project worth my time, especially with Java constantly on the blink.
5) No support - Few people care about working on oekaki, and almost every attempt I've seen to make a new board has fallen flat on its face. Even Mr. Chakkapark's new board, BJ Okekai, has gone nowhere in years. It's kind of depressing wanting to keep working on this stuff.
Now I can't believe this project is still up and running.. been a while since the old suteki.da.ne forum days.
Anyway, I was just browsing around and ran into this site again and did a bit of snooping and found these forums. I had one look at the software and I read the comments on how it isn't PHP 6 compatible... this has to change. I know that most servers I'm on have made the switch to PHP 5, and I doubt they'll wait around too long after the stable release of 6 before all converting. This poses many many changes, most of which the old time programmers who have developed habits will hate to start implementing.
Biggest problems:
1. Short tags.
- I got in the habit of using the long tags with the release of PHP5, but there are still lots of projects out there (including this one) that use short tags here and there. Now I haven't read up on PHP6 all that much, and I definitely haven't downloaded the snapshot, but does this also include short echo tags? <?=$var?>
From what I remember, I could have sworn OP had used short tags in that way at the very least.
2. MySQL as opposed to MySQLi
- This is something that SHOULD be implemented everywhere. It brings things up to PHP5 standards, nevermind PHP6. Has anyone run into a server that didn't have mysqli extension implemented? I don't see any reason why this should not change, and I heard a nasty rumor that mysql would be out in favor of mysqli in PHP6. That would pose LOTS of problems with the current code.
3. OOP vs the way it used to be
- Now I know that at one point in time Theo and the rest of us working on OekakiPoteto were going to make a fully OO version of OP, and we were going to make it open source. I guess that fell through, but that doesn't mean we can't still have object oriented code. Classes are the way of PHP5, and definitely should be implemented in order to clean up the code.
4. Things removed:
* register_globals
* magic_quotes
Wac isn't making use of register_globals on is it? I kinda think I remember that being one of the first things fixed. I don't really remember what was going on with the code, so who knows.... (maybe I should have had a closer look at it).
Also interesting is that magic_quotes is gone, so any database checks (if any) that look for it should be cleaned up.
5. Use prepared statements.
- Now I haven't even looked into this all that much. I've been toying with MySQLi, and I know prepared statements can definitely speed up queries in the long run. Reading the writeup on PHP6 tells me that prepared statements will definitely be the way to go with PHP6, and will probably be almost a no brainer in the future. This should be considered, although I think they're fairly new to MySQL5, so I doubt they'll be necessary.... still good to look into it!
6. ereg is gone!
Doing any regular expressions in the code the POSIX way? If so, it's out of PHP6... so all would have to be switch to something compatible.. ie: preg_match.
Anyway.. that's all of my input. It looks like a lot more work than it really is. The biggest problem would be moving from the current system to an object oriented system with classes and functions. Theo wasn't the cleanest coder out there, and he was quick to admit that it was all a learning experience. Wac 2.0 is in order?