The TERM environment settings for Terminal.app make a big difference in its behaviour. Normally with Terminal it's useful to have the TERM environment variable be 'xterm-color'. This will enable lots of interesting things, amongst them ANSI color. But, as described, this has it's drawbacks, including the fact that scrollback doesn't work as expected. Sometimes it's useful to launch any apps that need that functionality prefixed with 'TERM=vt100'. I run screen this way( 'TERM=vt100 screen') and it works much better as a result.
Alas, this doesn't affect speed but it does enable improved functionality.
It seems that a lot of people are kind of missing the technical point about what nefarious things Real Jukebox was really doing. When one understands the issues the only thing that real can be blamed for is bad marketing and documentation not evil technology.
The issue people that are up in arms about is that everytime a CD was introduced into the CDROM of a PC, Real Jukebox sends this information back to Real. That in and of itself seems quite a strong violation of one's privacy on the face of it, no? When left just at that, I too would agree that I wouldn't want Real to know what CDs I'm playing. But I think focusing on this without any further context is missing the point. And for some reason, this is the point that Real doesn't seem to be making for themselves.
In fact, I would argue that one of the best(value judgement) features of Real Jukebox is that when a new CD is introduced to a PC it "figures" out the artist and song titles. To me, this is a *good thing*. This has value. This means I can be lazy. I'd much rather not have to enter all this information by hand. Frankly, I'm quite content to give up a bit(*small*, *tiny*) of privacy to have all the CDs in my collection show up with full catalog information entered without any effort on my part.
I can appreciate that at some point, I have to "pay" for this useful feature. When choosing CD apps for my PC, this is a *required* feature for me. I will not use a CD player app that doesn't support CDDB. It's just too annoying to not have the artist and song title of what is playing immediately available.
But I also understand that unless some information necessarily needs to sent across the wire about *MY* cd collection to have this feature to work.. Did the people who were using Real Jukebox, DiscPlay, xmcd, whatever think that these programs were somehow magically capable of intuiting artist and song information. This seems obvious but seems to have been lost in the discussion. If you want the artist name and song titles of a new CD you have to be able to look it up in a database. And this means that at some point, you're at a minimum telling someone your IP address(NAT and other proxies notwithstanding) and the CD you're looking for. Of course, the CDDB database also wants "an email address" which is what is making things so tense this week.
What is quite striking about the current press and open source frenzy regarding this issue is how Real is getting lambasted for this feature. Why are they so special as to receive all this free publicity? What about all the others who were doing this long before Real?
In fact, this is not a novel Jukebox feature at all; the CDDB format has been around the 'net a long, long time. Why hadn't the privacy advocates been blasting those other programs? Was it because for the most part, CDDB has been implemented by open-source programs and that open-source programs were somehow above that level of scrutiny? No, I don't think so. The problem is that Real didn't educate people well enough about their program and its features. The types of people who were using an open-source CD player tend to also be the kinds of people who will automatically "get it" that for the player to know the song titles of their CDs they're going to have to give up some privacy to do the CDDB lookup. The average person using Real Jukebox, on the other hand, might not appreciate this technical point. In fact, they're probably more likely to think that Real Jukebox has an on disk database of all the CDs ever issued. Okay, they also prolly didn't think too hard about the new CDs they're buying either.
Real can dinged for bad documentation for not making this point better but I do not think that Real set out to invade people's privacy. They've been on record about not storing information anywhere and there is no reason to doubt the veracity of their statement. And for those who are offended by this, I recommend them to stop using Real Jukebox or DiscPlay and go back to using the CD player app that ships with windows, the one where you have to enter all the artist/title information by hand. I'll assume that the unix people understood the privacy trade off before this was a "NY Times"-worthy of an issue.
I haven't built an app using PHP but I've installed several for my own use. Most notably TWIG, which I highly recommend for an IMAP solution. So my comments are more based on observation as opposed to actual experience.
After going through the sources for mods that I wanted to make for the deployments, I couldn't help but feel somewhat anxious about how closely application logic and presentation layer are coupled in a PHP-based app. Coming from a 3-tier, Java, enterprise background, I can't help but think that there has to be a better way for decoupling these two.
It seems to me that the PHP/mysql combo is a good foundation for an HTML based application that does a lot of reads from but very few writes(especially possible contentious, inconsistent data writes) to a database. Dynamic content generation based on user preferences is a good candidate of what I'm describing here. Most writes to a db are by users changing "their world" within the site. Rarely does a user perform a write that could beOr even more simply, HTML views and updates of single database tables. PHP excels at this. What I don't see PHP/mysql being very good for is situations when mutliple database tables are to be modified within some kind of transactional state. PHP-based apps seem to shy away from allowing users to perform relatively complicated updates that would require data integrity across multiple database tables. I'm not saying that it isn't done, but the transactional overhead for the programmer to get this correct is just too high to attempt this often.
More importantly, however, given the 2-tierish n an app written in PHP, the overhead in changing how logic is performed seems to almost necessitate changes in how things look on the HTML page. Clearly, this is not a problem for quick one-offs, but starts to become a major issue when there are a lot of moving parts for a relatively large app.
My question to the PHP community is what are some good design ideas around which a PHP app can be decomposed. My comments are clearly being biased a standpoint of someone who has been using Java app servers to write 3-tier apps for awhile. I'm genuinely interested in knowing how the PHP world solves these problems.
Slashdot Mirror
The TERM environment settings for Terminal.app make a big difference in its behaviour. Normally with Terminal it's useful to have the TERM environment variable be 'xterm-color'. This will enable lots of interesting things, amongst them ANSI color. But, as described, this has it's drawbacks, including the fact that scrollback doesn't work as expected. Sometimes it's useful to launch any apps that need that functionality prefixed with 'TERM=vt100'. I run screen this way( 'TERM=vt100 screen') and it works much better as a result.
Alas, this doesn't affect speed but it does enable improved functionality.
It seems that a lot of people are kind of missing the technical point
about what nefarious things Real Jukebox was really doing. When one
understands the issues the only thing that real can be blamed
for is bad marketing and documentation not evil technology.
The issue people that are up in arms about is that everytime a CD was
introduced into the CDROM of a PC, Real Jukebox sends this information
back to Real. That in and of itself seems quite a strong violation of
one's privacy on the face of it, no? When left just at that, I too
would agree that I wouldn't want Real to know what CDs I'm
playing. But I think focusing on this without any further context is
missing the point. And for some reason, this is the point that Real
doesn't seem to be making for themselves.
In fact, I would argue that one of the best(value judgement) features
of Real Jukebox is that when a new CD is introduced to a PC it
"figures" out the artist and song titles. To me, this is a *good
thing*. This has value. This means I can be lazy. I'd much rather not
have to enter all this information by hand. Frankly, I'm quite content
to give up a bit(*small*, *tiny*) of privacy to have all the CDs in my
collection show up with full catalog information entered without any
effort on my part.
I can appreciate that at some point, I have to "pay" for this useful
feature. When choosing CD apps for my PC, this is a *required* feature
for me. I will not use a CD player app that doesn't support CDDB. It's
just too annoying to not have the artist and song title of what is
playing immediately available.
But I also understand that unless some information necessarily needs
to sent across the wire about *MY* cd collection to have this feature
to work.. Did the people who were using Real Jukebox, DiscPlay, xmcd,
whatever think that these programs were somehow magically capable of
intuiting artist and song information. This seems obvious but seems to
have been lost in the discussion. If you want the artist name and song
titles of a new CD you have to be able to look it up in a
database. And this means that at some point, you're at a minimum
telling someone your IP address(NAT and other proxies notwithstanding)
and the CD you're looking for. Of course, the CDDB database also wants
"an email address" which is what is making things so tense this week.
What is quite striking about the current press and open source frenzy
regarding this issue is how Real is getting lambasted for this
feature. Why are they so special as to receive all this free
publicity? What about all the others who were doing this long before
Real?
In fact, this is not a novel Jukebox feature at all; the CDDB format
has been around the 'net a long, long time. Why hadn't the privacy
advocates been blasting those other programs? Was it because for the
most part, CDDB has been implemented by open-source programs and that
open-source programs were somehow above that level of scrutiny? No, I
don't think so. The problem is that Real didn't educate people well
enough about their program and its features. The types of people who
were using an open-source CD player tend to also be the kinds of
people who will automatically "get it" that for the player to know the
song titles of their CDs they're going to have to give up some
privacy to do the CDDB lookup. The average person using Real Jukebox,
on the other hand, might not appreciate this technical point. In fact,
they're probably more likely to think that Real Jukebox has an on disk
database of all the CDs ever issued. Okay, they also prolly didn't
think too hard about the new CDs they're buying either.
Real can dinged for bad documentation for not making this point better
but I do not think that Real set out to invade people's
privacy. They've been on record about not storing information anywhere
and there is no reason to doubt the veracity of their statement. And
for those who are offended by this, I recommend them to stop using
Real Jukebox or DiscPlay and go back to using the CD player app that
ships with windows, the one where you have to enter all the
artist/title information by hand. I'll assume that the unix people
understood the privacy trade off before this was a "NY Times"-worthy
of an issue.
I haven't built an app using PHP but I've installed several for my own use. Most notably TWIG, which I highly recommend for an IMAP solution. So my comments are more based on observation as opposed to actual experience.
After going through the sources for mods that I wanted to make for the deployments, I couldn't help but feel somewhat anxious about how closely application logic and presentation layer are coupled in a PHP-based app. Coming from a 3-tier, Java, enterprise background, I can't help but think that there has to be a better way for decoupling these two.
It seems to me that the PHP/mysql combo is a good foundation for an HTML based application that does a lot of reads from but very few writes(especially possible contentious, inconsistent data writes) to a database. Dynamic content generation based on user preferences is a good candidate of what I'm describing here. Most writes to a db are by users changing "their world" within the site. Rarely does a user perform a write that could beOr even more simply, HTML views and updates of single database tables. PHP excels at this. What I don't see PHP/mysql being very good for is situations when mutliple database tables are to be modified within some kind of transactional state. PHP-based apps seem to shy away from allowing users to perform relatively complicated updates that would require data integrity across multiple database tables. I'm not saying that it isn't done, but the transactional overhead for the programmer to get this correct is just too high to attempt this often.
More importantly, however, given the 2-tierish n an app written in PHP, the overhead in changing how logic is performed seems to almost necessitate changes in how things look on the HTML page. Clearly, this is not a problem for quick one-offs, but starts to become a major issue when there are a lot of moving parts for a relatively large app.
My question to the PHP community is what are some good design ideas around which a PHP app can be decomposed. My comments are clearly being biased a standpoint of someone who has been using Java app servers to write 3-tier apps for awhile. I'm genuinely interested in knowing how the PHP world solves these problems.