XPath support XPath support is still preliminary. Some functions and numerical operators are missing and only abbreviated XPath syntax is supported. The parser has also some problems to recognize the full range of unicode characters. I have started to write a new XPath parser (using JavaCC instead of ANTLR) to overcome these limitations.
XUpdate The basic model has been designed to provide efficient, index based retrieval. As a drawback, eXist does currently not support direct manipulations of the DOM tree like node insertions or removals. A document always has to be deleted or updated as a whole.
This is clearly a major restriction for applications which need to directly manipulate the DOM tree. Such applications have to create a new document (as XSLT does) and insert this into the DB after all transformations are done. Documents should be kept small to easily reinsert them whenever they change.
DOM manipulation methods and XUpdate are planned for one of the next releases
I have done this earlier but that was a project so I dont have IPR for it. I can help you with this if I can find time this weekend [or if you pay my company:)] but essentially you need to do the following: - fix a platform. Since you only care for IMAP/POP and not calendering then sendmail/cyrus IMAP/qpop makes a good combination. There are others and your choice will at least be partly dictated by your religeous beliefs:) - now BACKUP your exchange store.. This is important in case anything goes bad at any stage. - write a script to migrate your windows/exchange users to freebsd+samba (if you want to include this - which you should, if you are worried about licensing). There is a good script inside samba distribution if you are on Exchange2000 but its not very difficult to write your own. If you do want to use RADIUS, there is a PAM available for that as well. - Beta test it. Users should be able to log-in with their older passwords and send/recieve mails. - write another script to transfer your mail stores from Exchange to IMAP. Since Exchange supports IMAP, this is not terrribly difficult. Your script should download files from Exchange over IMAP and copy them to your local FreeBSD mailstore (WITH THE SAME TIMESTAMP). - Beta test it again. - Open it to public. - Got it working !! Good!! Return that Exchange box and buy two small boxes to run more services on FreeBSD !!!
Well, I have been managing off-shore projects from India for about 5 years now and here is some advice rare on this board.
first of all cheer up. It is not as difficult as most people make it out to be:)
start by choosing the RIGHT company for the project. A right company is not necessarily big or small but one which has a similar style of functioning as yours. As you probably understands different companies have different levels of processes, different way of working essentially different cultures. Chose a company that is closer to yours. Ask bidding companies about their processes and cultures and to show you samples of their design documents, SRS, use cases, QA unit tests and whatever they have in their SE processes. And yes, it is possible to find companies in India with cultures not much different from American companies (not all of them are sweatshops).
There are lot of cheats and low-quality firms out here to swindle you. Look for references. Call your friends. When companies come to bid, ask them to give references you can check locally. Talk to american project manager of reference in detail (buy him/her lunch!!).
To be candid, in India level of professionalism is lower but value for human relationships is higher. Insist on talking to the actual project manager in India responsible for delievery IN PERSON before you give out the project. Ask the company to fly him to US.You only want to find answer to one question: CAN YOU TRUST HIM? (with your money? your kids?) If he is a trustable person then only give the project. (this point is impossible for an american to understand - they cannot make out why trusting your software is not very different than trusting your money)
Once you have awarded the project, consider your Indian partner as an extension of your company. Involve them in each stage of the project. Include them in requirement gathering and design stage. Ask them to fly-in at least some of their main guys and be a part of the process. Then, during the development stage chose a hybrid model. Have some (at least 20% of off-site) of the people from the Indian company work at your site while the rest work off-site. This will help ease communication barrier and help both companies understand each other cultures better. Indeed communication is the key to the project, insist on lots of email exchange, standardise on an IM client(yahoo, jabber, groove whatever) for the entire project team
P.S. contrary to opinion expressed in most mails. Time zone difference is an asset. I do most of my client calls from 7 to 11 pm India time which is early morning in US. Also, most of our first-time clients are pleasantly surprised to find that 40 bugs they reported last evening have reduced to 2 by today morning !!
As other people have pointed out, CGI/PHP/JSP scripts servlets etc are almost always more inherently insecure compared to SOAP. With SOAP, one can look at a particular HTTP header to find out which service or method is being called and if user has permissions to access it (one such opens source Apache module that does this is available here. (This module will alow you to selectively open SOAP services on per-user (or per-group) basis where users are authenticated by specifying a password or XML Signature.)
From adminstration point of view, it is definitly far more convinient to keep tab on just one port even when you are not a lazy administrator and watch, log and manually scan each suspicious packet going inside your network. and that is why SOAP is plus-plus. Also, I do not see how just using IIOP instead of HTTP increases security of a service accessed.
As other people have pointed out, CGI scripts etc are probably more inherently secure compared to SOAP. With SOAP, one can look at a particular HTTP header to find out which service or method is being called and weather user has permissions to access it (one such opens source Apache module that does this is available here. This will alow you to selectively open SOAP services on per-user (or per-group) basis where users are authenticated by specifying a password or XML Signature.
From adminstration point of view, it is definitly far more convinient to watch just one port even when you are not a lazy administrator and watch, log and manually scan each suspicious packet going inside your network. and that is why SOAP is plus-plus. I do not see how just using IIOP instead of HTTP increases the security.
A lot of people have suggested that battery life is a big issue. I would suggest that you enable this service only when you are in car when your phone is hooked onto your car battery and you have a big ass antenna on top of the car [giving you maybe 100x factor on battery power and range (from a regular handheld cellphone)].
This could be of immense help during emergencies as people in car would help others in relaying messages. Volunteers can bring a suffecient number of cars near the emergency accident site to allow people to communicate (large number of base stations nearby should help save battery life for people buried in rubble).
I work for a smart-card solutions company in India and was the technical lead for a team that wrote software for India's largest installation of smart-cards which in India is larger than most credit cards. I have also been asked to present my views in front of RBI (India's fedral bank) sponsered committee to create standards for smart-card use in the country.
Coming to technical details, a smart card basically acts like a secure computer with a secure filesystem and operating system of its own. It exposes a limited set of "system calls" that you can call from inside your program which are supposed to be secure (at least in theory).
For example, the system calls may allow you to "write" a private key to a "file" in smart card froma program but having once written the private key you are not allowed to modify or read it back. There will be a seprate set of "system calls" that will allow you to decrypt or sign messages using this key however (after giving one or more PIN(s)). As a card is small and can be easily hidden or transported under rugged enviroments this allows a very secure and convenient place to keep critical private keys. Such cards are commercially available and are programmable from Windows and Java (A free linux version in C is being done by MUSCLE guys). There is nothing more or nothing less to smartcard technology.
As you can imagine one can leverage this simple use and storage of assymetric (and also symetric) keys to design wonderful credit-card (or other financial) solutions that can provide almost complete privacy and fraud-control. However,it is not technology but the corporates and government which are limiting the use of smart cards.
For example, in India a large number of people (especially with money from dubious sources) used to spend by buying stored value smart cards which were available off the counter for cash. Till income-tax department decided to make it compulsory to record identification details for each such transaction. One can argue that it was a blow to privacy but does the govt has an option in front of brazen money laundry?
This is not bound to change any time in near future. As soon as you make financial transactions anonymous, guys who got "bad money" get in and start using the system for their own laundry.
However, fraud-control is on everybody's list and one should expect VISA and MasterCard to move in this direction. As somebody else pointed out, there is a lot of investment done by merchants and banks in current terminals and rest of the credit-card infrastructure so one should not expect new technology to come out overnight. however, over next 5-10 years I would expect a lot more credit cards to be chip-based with at least PIN protection on them
The first thing you should think about is whether you need an application server. If your concern is speed for a medium volume website can do with mod_perl or zope or something.
However, if you are looking for high scalablity and reliablity for top-end system with large volumes of transaction processing then do not hesitate, you really need it.
In that case, there are three application servers worth considering: 1) BEA Weblogic 2) Sun-AOL iPlanet 3) IBM WebSphere EE
Which one you chose depends on what are your concerns and goals.
iPlanet has the best support for failover clustering and load-balancing but I find it too proprietary with its own tags to script. If you are also concerned about that then chose WebSphere that has good failover mechanism but not enough of load-balancing and transaction failover components but is mostly non-proprietery.
If you plan to do large distributed transaction processing websphere is the way to go which has intgeration with third-party DTCs and strong support for client initiated transactions. Weblogic has virtually no support for distributed transactions and iPlanet also lags behind far.
Websphere has also good support for XML and other object services like running RMI and IIOP over SSL. (weblogic needs third party components to run IIOP over SSL, iPlanet does not suport RMI or IIOP over SSL. Both have no support for XML)
However, weblogic provides strong support for dynamic content presentation and session tracking but the other two are not too far behind either.
iPlanet has nice security audit features and the other two lag behind here, however this is not too much of strength as I always end up writing my own audit functions(tho, YMMV).
iPlanet also supports SNMP which other two don't and this could be a deciding factor sometimes.
Out of three only websphere is supported on linux.
One more thing, this is not really an ad, but my company does exactly this kind of work and I could ask my marketing guys to follow up with you if you are looking to outsource either design or implementation:-). I am not saying this because I work here but because I know we guys really know our work.
P.S. There is a nice comparison of AS's at http://www.flashline.com/components/appservermatri x.jsp
No actually this is not true. I do a lot of work on application servers including WebLogic, WebSphere and NetDynamics (now merged in iPlanet). These projects offer a whole lot of features as standard which would typically take a long time to put in place otherwise. For example automatic failover at transaction and application level, nice integration with transaction processing systems and seamless integration of development environment. I agree that most of things could be developed in house but why reinvent the wheel. And in most applications a little slowness could be compensated by superior hardware and a more important concern is long term maintainace and running of such a large code base that typically get created.
Slashdot Mirror
From eXist homepage,
XPath support XPath support is still preliminary. Some functions and numerical operators are missing and only abbreviated XPath syntax is supported. The parser has also some problems to recognize the full range of unicode characters. I have started to write a new XPath parser (using JavaCC instead of ANTLR) to overcome these limitations.
XUpdate The basic model has been designed to provide efficient, index based retrieval. As a drawback, eXist does currently not support direct manipulations of the DOM tree like node insertions or removals. A document always has to be deleted or updated as a whole.
This is clearly a major restriction for applications which need to directly manipulate the DOM tree. Such applications have to create a new document (as XSLT does) and insert this into the DB after all transformations are done. Documents should be kept small to easily reinsert them whenever they change.
DOM manipulation methods and XUpdate are planned for one of the next releases
I have done this earlier but that was a project so I dont have IPR for it. I can help you with this if I can find time this weekend [or if you pay my company :)] but essentially you need to do the following: :)
- fix a platform. Since you only care for IMAP/POP and not calendering then sendmail/cyrus IMAP/qpop makes a good combination. There are others and your choice will at least be partly dictated by your religeous beliefs
- now BACKUP your exchange store.. This is important in case anything goes bad at any stage.
- write a script to migrate your windows/exchange users to freebsd+samba (if you want to include this - which you should, if you are worried about licensing). There is a good script inside samba distribution if you are on Exchange2000 but its not very difficult to write your own. If you do want to use RADIUS, there is a PAM available for that as well.
- Beta test it. Users should be able to log-in with their older passwords and send/recieve mails.
- write another script to transfer your mail stores from Exchange to IMAP. Since Exchange supports IMAP, this is not terrribly difficult. Your script should download files from Exchange over IMAP and copy them to your local FreeBSD mailstore (WITH THE SAME TIMESTAMP).
- Beta test it again.
- Open it to public.
- Got it working !! Good!! Return that Exchange box and buy two small boxes to run more services on FreeBSD !!!
P.S. contrary to opinion expressed in most mails. Time zone difference is an asset. I do most of my client calls from 7 to 11 pm India time which is early morning in US. Also, most of our first-time clients are pleasantly surprised to find that 40 bugs they reported last evening have reduced to 2 by today morning !!
As other people have pointed out, CGI/PHP/JSP scripts servlets etc are almost always more inherently insecure compared to SOAP. With SOAP, one can look at a particular HTTP header to find out which service or method is being called and if user has permissions to access it (one such opens source Apache module that does this is available here. (This module will alow you to selectively open SOAP services on per-user (or per-group) basis where users are authenticated by specifying a password or XML Signature.)
From adminstration point of view, it is definitly far more convinient to keep tab on just one port even when you are not a lazy administrator and watch, log and manually scan each suspicious packet going inside your network. and that is why SOAP is plus-plus. Also, I do not see how just using IIOP instead of HTTP increases security of a service accessed.
As other people have pointed out, CGI scripts etc are probably more inherently secure compared to SOAP. With SOAP, one can look at a particular HTTP header to find out which service or method is being called and weather user has permissions to access it (one such opens source Apache module that does this is available here. This will alow you to selectively open SOAP services on per-user (or per-group) basis where users are authenticated by specifying a password or XML Signature.
From adminstration point of view, it is definitly far more convinient to watch just one port even when you are not a lazy administrator and watch, log and manually scan each suspicious packet going inside your network. and that is why SOAP is plus-plus. I do not see how just using IIOP instead of HTTP increases the security.
A lot of people have suggested that battery life is a big issue. I would suggest that you enable this service only when you are in car when your phone is hooked onto your car battery and you have a big ass antenna on top of the car [giving you maybe 100x factor on battery power and range (from a regular handheld cellphone)].
This could be of immense help during emergencies as people in car would help others in relaying messages. Volunteers can bring a suffecient number of cars near the emergency accident site to allow people to communicate (large number of base stations nearby should help save battery life for people buried in rubble).
I work for a smart-card solutions company in India and was the technical lead for a team that wrote software for India's largest installation of smart-cards which in India is larger than most credit cards. I have also been asked to present my views in front of RBI (India's fedral bank) sponsered committee to create standards for smart-card use in the country. Coming to technical details, a smart card basically acts like a secure computer with a secure filesystem and operating system of its own. It exposes a limited set of "system calls" that you can call from inside your program which are supposed to be secure (at least in theory). For example, the system calls may allow you to "write" a private key to a "file" in smart card froma program but having once written the private key you are not allowed to modify or read it back. There will be a seprate set of "system calls" that will allow you to decrypt or sign messages using this key however (after giving one or more PIN(s)). As a card is small and can be easily hidden or transported under rugged enviroments this allows a very secure and convenient place to keep critical private keys. Such cards are commercially available and are programmable from Windows and Java (A free linux version in C is being done by MUSCLE guys). There is nothing more or nothing less to smartcard technology. As you can imagine one can leverage this simple use and storage of assymetric (and also symetric) keys to design wonderful credit-card (or other financial) solutions that can provide almost complete privacy and fraud-control. However,it is not technology but the corporates and government which are limiting the use of smart cards. For example, in India a large number of people (especially with money from dubious sources) used to spend by buying stored value smart cards which were available off the counter for cash. Till income-tax department decided to make it compulsory to record identification details for each such transaction. One can argue that it was a blow to privacy but does the govt has an option in front of brazen money laundry? This is not bound to change any time in near future. As soon as you make financial transactions anonymous, guys who got "bad money" get in and start using the system for their own laundry. However, fraud-control is on everybody's list and one should expect VISA and MasterCard to move in this direction. As somebody else pointed out, there is a lot of investment done by merchants and banks in current terminals and rest of the credit-card infrastructure so one should not expect new technology to come out overnight. however, over next 5-10 years I would expect a lot more credit cards to be chip-based with at least PIN protection on them
The first thing you should think about is whether you need an application server. If your concern is speed for a medium volume website can do with mod_perl or zope or something.
:-). I am not saying this because I work here but because I know we guys really know our work.
i x.jsp
However, if you are looking for high scalablity and reliablity for top-end system with large volumes of transaction processing then do not hesitate, you really need it.
In that case, there are three application servers worth considering:
1) BEA Weblogic
2) Sun-AOL iPlanet
3) IBM WebSphere EE
Which one you chose depends on what are your concerns and goals.
iPlanet has the best support for failover clustering and load-balancing but I find it too proprietary with its own tags to script. If you are also concerned about that then chose WebSphere that has good failover mechanism but not enough of load-balancing and transaction failover components but is mostly non-proprietery.
If you plan to do large distributed transaction processing websphere is the way to go which has intgeration with third-party DTCs and strong support for client initiated transactions. Weblogic has virtually no support for distributed transactions and iPlanet also lags behind far.
Websphere has also good support for XML and other object services like running RMI and IIOP over SSL. (weblogic needs third party components to run IIOP over SSL, iPlanet does not suport RMI or IIOP over SSL. Both have no support for XML)
However, weblogic provides strong support for dynamic content presentation and session tracking but the other two are not too far behind either.
iPlanet has nice security audit features and the other two lag behind here, however this is not too much of strength as I always end up writing my own audit functions(tho, YMMV).
iPlanet also supports SNMP which other two don't and this could be a deciding factor sometimes.
Out of three only websphere is supported on linux.
One more thing, this is not really an ad, but my company does exactly this kind of work and I could ask my marketing guys to follow up with you if you are looking to outsource either design or implementation
P.S. There is a nice comparison of AS's at http://www.flashline.com/components/appservermatr
No actually this is not true.
I do a lot of work on application servers including WebLogic, WebSphere and NetDynamics (now merged in iPlanet).
These projects offer a whole lot of features as standard which would typically take a long time to put in place otherwise. For example automatic failover at transaction and application level, nice integration with transaction processing systems and seamless integration of development environment.
I agree that most of things could be developed in house but why reinvent the wheel. And in most applications a little slowness could be compensated by superior hardware and a more important concern is long term maintainace and running of such a large code base that typically get created.