evilguru

- Anything you can do with PHP, you can do with JSP; the reverse is not true

Care to elaborate? Anything I can do in JSP I can also do in C, which I can also do in assembler. I can also do things in C which I can not do in Java (direct memory access, for example). Therefore using that logic all websites should be written in C.

- JSP is much more powerful, since it has access to all the Java libraries. PHP only has access to PHP libraries

C has access to all of the PHP and Java libraries (using the appropriate bridges). C wins again.

- JSP is Object-Oriented, so leads to cleaner code that's easier to debug, maintain, and improve. (PHP also allows objects, but the - object model is more primitive, and most scripted pages ignore PHP objects and just use normal variables.)

PHP5 supports almost exactly the same object model as Java. Abstract classes, interfaces, public, protected and private member variables/functions, pass by reference, static functions/variables.
Your second point (about developers ignoring such features) notwithstanding; the features of a language exploited by its respective community is irrelevant when comparing languages. The fact of the matter is they exit.

By inflection you are also categorically static that object orientated code is always better. I dispute that. If Java was multi paradigm (like PHP or C++) I wonder how many people would forgo the object orientated features in some situations.

- The equivalent syntax in JSP is just as simple to learn, so you can get up and running just as quickly -- that is, there's no extra startup cost in using Java, at least not a significant one

The number of hosts supporting JSP is smaller than that of PHP. The PHP community is significantly larger (for the hobbiest sector anyway). I know both Java (I normally use Swing/SWT, so desktop apps) and can tell you it is a lot harder than PHP.
Try explaining to a beginner how to connect to a MySQL/PostgresSQL database in Java using JDBC and then compare it to the required PDO code.

- Java programmers (as opposed to 15-year-old hackers or HTML monkeys) appreciate the importance of a clean language with complex OO data structures and strong typing

Again, this is not a language thing, but more a social one. Notwithstanding.

- With JSP, if the code inside a page gets too big, or if you want to use it elsewhere, you can cut it out, make it into a Java class, and invoke it from anywhere in your application (even not from a page). With PHP, you're stuck inside the HTML box.

100% not true. On the lowest level PHP supports including of other PHP files. Boom, a simple template system. Further up the food chain there is Smarty (a true templating language) and even further up there is ezcComponents and the Zend Framework, which provide the MVC design pattern to PHP.

- JSP's concept of state management and persistence is more explicit and powerful than PHP's. With JSP, you can specify whether a variable persists for the page, the request, the session, or the application (or if it's just local to the function). The JSP engine automatically does the right thing with cookies so you have access to the variable on later requests. With PHP, you just have "global" and "not global", you don't have automatic session management, and have to do your state thing manually with cookies or hidden variables.

PHP has sessions http://forums.xisto.com/no_longer_exists/ . They are 100% transparent to both the programmer and user.
Regards, Freddie.

I have looked into it and it is not a problem on my side, it seems to be that libgmailer is in need of an update, I am not sure when this will come but hold onto your seats, they are normally a great bunch of guys and should have a new version ready before we even know it!

You spoke to soon I am afraid, it has just stopped working again, however I am hot on the case and will tell you as soon as I have got it working again as well as where you can find the newest zip file.

Hi, I am starting development of the project once again and I would like some help from you guys. I am going to create a sourceforge account soon as well as looking for people who wantto help with the development of the project. So I am open for feature requests.Thanks again for your support.

It took about 30 min! The real credit should be going to the creator of libgmailer.

On a side note, I do not think that google will ever be able to stop this, as if they change their javascript packets etc we are still able to access Gmail using POP3 (php imap functions will do the job), and that was my original plan, to use my own POP3 lib to access the account but then libgmailer turned up and made my job a lot easier.

It is not dead yet! Every few months Gmail changes how their XMLHTTPRequest packets are sent, and the JavaScript that parses them, this is often done to add new features to the system, and to improve elements of it, this is normal. However, sometimes some of these changes can break the code from libgmailer (and the .net parser which it is ported from). I am not sure when this update happend, I was only told about it in the last 20 min. The fix is simple, I just had to update the version of libgmailer to the newest version on sourceforge and make a couple of small changes. You can find the new version of libgmailer.php here: http://www.dcrez.co.uk/create/gmail/libgmailer.zip Just upzip it and then replace the current version of libgmailer.php with the new version from the zip file. My online version has been updated, and I have almost finished the new version off.

Hello everybody I have now added zip support to the system. The solution was quite simple, if the type of the attachment is application/zip then send the file out as:

an octet-stream and explicitly specify the filename. The bad news is that for every type of file which the browser can not handle I need to set up to use an octet stream. Might be faster to only not do it for certian file types, we will see. The code for it is:

if ($conv->conv[$id]["attachment"][0]["type"] == "application/zip") {	header('Content-type: application/octet-stream'); 	header('Content-Disposition: inline; filename="' . $conv->conv[$id]["attachment"][0]["filename"] . '"');}else {	header('Content-type: ' . $conv->conv[$id]["attachment"][0]["type"]);}

Works on firefox, ie and opera (only ones I have). You can integrate it yourself, or wait for the new version which will have full datatbase user support as well as bandwidth limits (daily limits) which will allow people like me to provide a 'public' version of the service.

You can see it here: http://www.dcrez.co.uk/create/gmail/gmail2.php?id=test&q=zip

FYI, gmail2.php is the user accounts version, which uses a database and it just happens that my chosen 'handle' for my project.website@gmail.com account is 'test'.

Regards, Freddie (aka EvilGuru).

The problem itself is not with libgmailer, but with how the browser handles appliction/xxxx streams, as these can not be 'shown' in the browser so it takes to download them. With a zip file it will download it under the name gmail.php and if you have any text-editors associtated with .php files it will try to open it in them (as it thinks it is downloading a .php file due to the extension .php). I believe there are ways to get past this problem and am looking into them. The same is true of mpg files.

 

I have just added support for different users, but it is still in very early stages. If you would like to use it go to:

http://www.dcrez.co.uk/create/gmail/account.php and 'create' an account (in which the information is added to a MySql database), then to view it you can do http://www.dcrez.co.uk/create/gmail2.php?id handle>&q=<subject of email> where <your handle> is the handle of the account you created and <subject of email> is the subject of the conversation in which to read the first attachment from. Still got a fair bit of work to do on it however.

Hello, you can find the source code for the program here: http://www.dcrez.co.uk/create/gmail/gmail.zip

It has been tested on PHP 4.3.11 (red hat) and PHP 5.0.4 (win, IIS). To use it all you need to do is edit Gmail.php replacing <user> and <pass> with your Gmail user name and password for the storage account you will be using (there is NO way for the user to ever see your Gmail user name or password as it is all server side). The system itself is very simple, it searches your Gmail account for a conversation in which the subject is the same as a $_GET['q'] argument (mails which have not been read yet are returned as <b><subject></b>, so I strip the <b> tags first).

I use an edited version of the open source libgmailer 0.7a (http://forums.xisto.com/no_longer_exists/), with the changes being to how attachments are handled, libgmailer by default overides the CURL output settings, getting it to write to a file so I have changed this back to the CURL default (browser) and commented out some session stuff. There are still some changes to made (eg page support needs to be a bit better).

Hope you all like it