[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] thanks re mimencode
Re: [Gnumed-devel] thanks re mimencode
11 May 2002 09:28:32 +1000
On Sat, 2002-05-11 at 08:26, Horst Herb wrote:
> On Fri, 10 May 2002 22:48, syan tan wrote:
> > so is java ever likely to become a language where developers that stay
> > with gnu license , are going to need to pay fees? python is getting a
> > little commercial recently , so how does the freedom differ?
> Java was never a free language, and explicitly designed to promote
> proprietary code. What is this about Python going commercial? Python is
> licensed GPL - thus it will always remain free.
> > I suppose the more heavily reliant one becomes on the ever expanding
> > java libraries, the more likely sun is going to slap a not for
> > distribution without paying homage etc...
> That and the undemocratic process of dictating what "complies" with Java
> standards has put me off completely of Java. and, I think it is a quite
> unreadable language, where you immediately get lost w/o class browsers.
> > implementations for the gmPerson... stuff, I noticed I'm likely to be
> > completely binding the client ui code with the names of fields and
> > tables in the postgres server table conglomeration. On the other hand,
> This is why we suggested there be one function data->interface and one
> function interface->data instead of direct mapping of singular widgets to
> data. We want to keep the program logic a bit more independend of the
> choice of interface.
> Ask yourself: "what do I want to achieve with this dialogue?" The answer
> most often is display, and/or edit, and/or add data. So write a library
> that allows you to do exactly this with the data you refer to in the most
> comfortable and straightforward way. Once it works, bind it to the user
> interface of your choice, because there will be many ways to go to Rome.
> Users have different preferences regarding user interfaces, and what suit
> the "majority", might not suit you or me.
> > Is three tier unnecesary for the scope of gnumed ? Or is the
> > availability of views and triggers in sql sufficient as the middle tier?
> I had implemented a middle tier in C++. The client connected via TCP/IP
> (SSL) to it, and it connected to the backend via TCP/IP (SSL). However, it
> turned out to be a performance bottleneck (instead of the opposite) and
> had no advantages whatsoever regarding security as it always could be
> bypassed some way or another. The main feature (replication) was thus not
> reliable, and all the effort of parsing teh query tree twice (once on teh
> middle tier, once on the backend) was futile.
> Gnumed-devel mailing list
I agree partially with the idea that roll your own middle tier can seem
to have no point when the pgdb api basically converts between simple
python collection types and database types with a minimalist API. I've
tried application specific data objects/structs , and passing them
through remote method invocation, and it does add a layer of complexity
to development and debugging that make you wonder if it is worth it.
What you want is that if a table is changed or relationship added,
I'm not sure how ssl can be bypassed, but may be you mean if someone
goes into the protocol and intercepts at a low level ( eg. ip packets) ,
it could be possible to spoof client or server authentication and
present fake keys for key exchanges, although I'm not sure how one could
fake timestamped encrypted public private key protected session key
exchanges: spoof the public key authority servers? How can you do
spoofing , if say you are dial-up connected into an organizational
intranet e.g. bigpond domain, that might mirror a DNS for the Internet?
I suppose one way would be to be able to gain administrative control of
some routers connecting the bigpond domain to the internet, and then
doing ip sniffing and ip packet spoofing for DNS related traffic. Does
anyone want to give a brief overview of security problems that are
current and interesting? I'm just rambling to understand security.
For instance, the/ a weak point in the cvs developer system, is the
password. Once the password is obtained, anyone can paste a public key
in the key mods textarea and pretend to be the developer and make
commits. Hopefully, cvs being a versioning system, it is potentially
easier to find changes related to non-benign coding, e.g. trojan data
capture code, if a security problem develops.
BTW, does anyone know if python was coded so that address space
violations don't happen, e.g. buffer write length limits in all input
But who would want to break into a small project like this?