![]() |
Messing with Serialization
For a more detailed reason on why I'm doing this read here.
The idea behind this is that when PHP serializes an array it generates a string that contains all the information to recreate the array. However, I would like to be able to separate the array keys (keys that are exclusively strings) from the serialized string itself. So that I would have the keys in one string and the values of the array in another. I would also like to be able to recombine the two strings into the original serialized string. So here's the code I wrote up to do this: :
class gbSerializer { |
Re: Messing with Serialization
You could read the string much more easily with a regular expression.
Perhaps I don't fully understand the problem, but couldn't you just create separate arrays of the keys and values and use the built-in serialization functions to store them? That is, assuming the order of the objects is retained. |
Ya sorry titanium I guess I didn't say exactly what the issue was, let me try a more concrete problem statement:
|
Re: Messing with Serialization
This is the latest refinement I made to the gbSerializer class and it works as I expect it to. Just curious if anyone could see a way I might refine it better.
:
class gbSerializer { |
Re: Messing with Serialization
Your solution seems so arbitrary. Have you tried to address the base problem of it all: file permissions? Since the new files default to a certain permission, have you tried chmodding them after creation? Have you tried setting .htaccess, contacting your server hosting's support, or looking for a synthetic-file-permissions solution that already exists?
Just saying. |
Re: Messing with Serialization
Well here I'm not dealing with the problem of file permissions. I'm actually trying to find a way to reduce the amount of wasted bytes in the database. However, yes I have tried chmodding them to other permissions. Again the server treated them all as 777 even if it said something different in my FTP program. htaccess files were also not respected. This all happened on a free server and yes I wrote up on their forums and they said if you want privacy on your stuff you gotta pay. Solution was obviously to switch server and do what you're stating Sane. However, that would've meant I would've isolated everyone who wanted to store their files there. This solution on the other hand will work everywhere, because wherever there's a PHP engine it will parse out comments. So no risk of anything being seen.
|
Re: Messing with Serialization
It seems innovative, I'll give you that. I'm just not so sure how many people would agree it's the most beneficial solution for reasons that I'm sure you could evaluate yourself. Either way, neat stuff. Get a sourceforge page up! See if others can contribute their ideas to make it a more fully-encomposing solution.
|
Re: Messing with Serialization
Actually, GrimBB has a sourceforge page Sane. However, I found the sourceforge system very complicated. That's just me, it was complicated for me, I'm not trying to say the sourceforge system is complicated or is no good or anything. So I just removed the project source from there and basically just use sourceforge as a redirect to the GrimBB site. Interestingly enough I used the system to document like a bug or vulnerability or something, and suddenly the net was bombarded with GrimBB XSS Vulnerability security issues or something or other lol. The Brainstorming forum on my site is for those ideas. Of course I'd need actual traffic there but ay, that's why it's just my hobby ^_^
|
Re: Messing with Serialization
I was talking about your solution. Not GrimBB.
|
Re: Messing with Serialization
Hmm, I don't believe anyone has written a fully-functioning stand-alone relational database purely in .php before. That would be pretty nifty, and would have been perfect for GrimBB (instead of integrating a custom "database"). I should try that. Would be very fun.
|
| All times are GMT -5. The time now is 12:45 PM. |
Powered by vBulletin® Version 3.7.0, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2007 DaniWeb® LLC