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 - AngelinaBelle
76
Other software / Re: Wedge and SMF directions
« on June 7th, 2011, 10:08 PM »
I'm sorry I've shifted this topic so far off-topic. I'm not going to try to heal any rifts today.
I like "floating topics" by any other name, because content is content to me.
Best
I like "floating topics" by any other name, because content is content to me.
Best
77
Other software / Re: Wedge and SMF directions
« on June 7th, 2011, 06:13 PM »
After the licensing change promissed with SMF 2.0Final, my understanding is that any fork of SMF 2.0Final is OK.
Some team members are not the "official" team, or even all team members, anyway.
I know you and Nao are far better matched over here than either of you was at SMF.
It *IS* sensible to work together when two groups have a common interest.
If you do drop out of SMF completely with the 2.0 final release, I'll guess I'll really miss you. That's just a fact. No guilt. Of course, I've been totally missing Nao over there for some time.
Some team members are not the "official" team, or even all team members, anyway.
I know you and Nao are far better matched over here than either of you was at SMF.
It *IS* sensible to work together when two groups have a common interest.
If you do drop out of SMF completely with the 2.0 final release, I'll guess I'll really miss you. That's just a fact. No guilt. Of course, I've been totally missing Nao over there for some time.
78
Other software / Re: Wedge and SMF directions
« on June 7th, 2011, 05:23 PM »
All fascinating discussions. Seriously. I miss you guys frequently. Even though, Arantor, you are kind of still there on the friends board to share your acquired knowledge and help out in crises.
79
Other software / Re: Wedge and SMF directions
« on June 7th, 2011, 05:04 PM »
I'm not part of the dev crew at SMF, though I sometimes participate in discussions with them.
I just know that the SMF devs will have to adress these exact same issues. It is only logical.
Just as it is only logical to assume they'll also have to adress IPV6 -- failure to do so would cause problems on oodles of forums.
I'm always curious, and I respect the experience of Arantor and Nao. I've read small swatches of Nao's AEVA code and enjoyed it, too. They seem to make a good team over here, and I wish their knowledge and experience were feeding directly into designing SMF. But I can't always get what I want.
And, thanks for asking, you did get my gender right.
-----
P.S. I am not making definitive statements about what dev team WILL do, only my opinions about what they will NEED to do. I cannot speak for SMF's dev team. Or for any other part of SMF or the SimpleMachines organization. I'm apologize if I implied otherwise. Next time, I'll try to remember to say "I think they will need to do X"
I just know that the SMF devs will have to adress these exact same issues. It is only logical.
Just as it is only logical to assume they'll also have to adress IPV6 -- failure to do so would cause problems on oodles of forums.
I'm always curious, and I respect the experience of Arantor and Nao. I've read small swatches of Nao's AEVA code and enjoyed it, too. They seem to make a good team over here, and I wish their knowledge and experience were feeding directly into designing SMF. But I can't always get what I want.
And, thanks for asking, you did get my gender right.
-----
P.S. I am not making definitive statements about what dev team WILL do, only my opinions about what they will NEED to do. I cannot speak for SMF's dev team. Or for any other part of SMF or the SimpleMachines organization. I'm apologize if I implied otherwise. Next time, I'll try to remember to say "I think they will need to do X"
80
Other software / Re: Wedge and SMF directions
« on June 7th, 2011, 04:42 PM »
OK -- the first step is somehow creating sensible code, whether from scratch or as a rewrite of existing code and its accumulated hacks/cruft.
81
Other software / Wedge and SMF directions
« on June 7th, 2011, 03:58 PM »
WEDGE seems like a sort of 2.0 alternative. Maybe more of a 2.1 alternative at this point.
Using more sensible data structures (in the code as well as in the DB) makes sense. First, write sensible, understandable code. Then optimize performance. I know that SMF 3.0 will have to do this. I wouldn't expect you guys to be thinking any differently.
Using more sensible data structures (in the code as well as in the DB) makes sense. First, write sensible, understandable code. Then optimize performance. I know that SMF 3.0 will have to do this. I wouldn't expect you guys to be thinking any differently.
82
Features: Upcoming / Re: Floating topics
« on June 3rd, 2011, 06:30 PM »
I think this is a good idea, too. I almost missed your post because I misunderstood the subject "floating topics". This is really a generalization of the idea that a msg_id can belong to a topic, a reply, a blog post or blog comment. It could also belong to a portal article, or an item associated with any other kind of thing we could think of bolting onto a simple website machine.
Will it require overhauling data structures, tables, and "business logic" on how items are retrieved? Either the topic_id and board_id columns will be generalized, or else (horrors) we go to third-normal form and lose optimization?
Will it require overhauling data structures, tables, and "business logic" on how items are retrieved? Either the topic_id and board_id columns will be generalized, or else (horrors) we go to third-normal form and lose optimization?
83
Off-topic / Re: Why the hell has no-one thought of this before?
« on April 14th, 2011, 02:04 PM »
F/X or decent dialog. Your choice.
84
Features / Re: Naming Boards/blogs/sites etc.
« on April 13th, 2011, 07:40 PM »
Thanks for trying all these ideas out, Nao and Arantor. Maybe the entire SMF community can profit from what you learn.
85
Features / Re: Naming Boards/blogs/sites etc.
« on April 13th, 2011, 07:33 PM »
Darn. Sound like I'll be hating parse_bbc for a long time, then.
86
Features / Re: Naming Boards/blogs/sites etc.
« on April 13th, 2011, 07:19 PM »
bbc versioning.
I am given to understand, from some of [Unknown]'s posts, that a significant part of the complexity/resource-hogginess of parse_bbc is to support "backwards compatibility". I can't quite follow how parse_bbc picks the correct version of a given tag. And I don't know what all other stuff is in there for "backwards compatibility"
Declare all "old" posts to belong to "old parse_bbc" and let "old parse_bbc" parse them.
Force new posts to conform to "new bbc" usage, and use a "new parse_bbc" to parse them.
As the old posts recede into history, "old parse_bbc" will be called less and less often.
And "new parse_bbc" will be called more and more often, for a modest performance improvement.
Portal and AJAX chatbox authors have already found that drastically reducing the size of parse_tags can yield very large performance improvements.
I am given to understand, from some of [Unknown]'s posts, that a significant part of the complexity/resource-hogginess of parse_bbc is to support "backwards compatibility". I can't quite follow how parse_bbc picks the correct version of a given tag. And I don't know what all other stuff is in there for "backwards compatibility"
Declare all "old" posts to belong to "old parse_bbc" and let "old parse_bbc" parse them.
Force new posts to conform to "new bbc" usage, and use a "new parse_bbc" to parse them.
As the old posts recede into history, "old parse_bbc" will be called less and less often.
And "new parse_bbc" will be called more and more often, for a modest performance improvement.
Portal and AJAX chatbox authors have already found that drastically reducing the size of parse_tags can yield very large performance improvements.
87
Features / Re: Naming Boards/blogs/sites etc.
« on April 13th, 2011, 06:36 PM »
I understand what you are saying. I just think differently than you do.
Probably because you have more and better coding experience.
Probably because you have more and better coding experience.
88
Features / Re: Naming Boards/blogs/sites etc.
« on April 13th, 2011, 06:26 PM »
I'd rather string together existing code than write a bunch of new code, just to do a conceptually simple customization of a SimplePortal block that now uses ssi_recentPosts because that did what the designers wanted it to do.
Thanks for letting me know where you stand vis-a-vis parse_bbc. I hates it -- parse_bbc.
Thanks for letting me know where you stand vis-a-vis parse_bbc. I hates it -- parse_bbc.
89
Features / Re: Naming Boards/blogs/sites etc.
« on April 13th, 2011, 05:53 PM »
If you ever start to want a very content-rich portal page, with several blocks doing different things, you might see parse_bbc differently.
Or you might not get hung up on the same things that us less-experienced coders break our teeth on.
Or you might not get hung up on the same things that us less-experienced coders break our teeth on.
90
Features / Re: Naming Boards/blogs/sites etc.
« on April 13th, 2011, 05:21 PM »
Solving parse_bbc problems is a bear.
So -- add some parameters in SSI.php to either do what I want it to do or tell it I'll parse my own bbc.
So -- add some parameters in SSI.php to either do what I want it to do or tell it I'll parse my own bbc.