> Do you have to access that storage from different programs? If not > then you could just transfer the information to the new (slightly > different) database structure.
Well, yes. That's part of the reason for using LDAP, in that browsing clients can use it directly. So one interface would be web based, using webware, there would be a managment portion, also webbased, and then there would be these clients would would talk LDAD natively, but would only be browsing the directory. For a more typical web application, there are probably still reasons to use a database directly and also access it from webware. > Not only doesn't MK deal well with legacy databases, I don't think it > would deal well at all with non-MK clients accessing and updating the > database. At least that is my impression, as MK does a lot of > caching. I'd like to hear Chuck's comments on this too. Chuck, (or others who are using MK), are you using the data without MK often? And if so how does that work? > The database does caching itself, and personally I'd rather keep the > caching flat -- caching at the Python level saves some communication > overhead, and also caches what calculations occur to create the Python > object (which should really be small anyway)... but if you are > allowing multiple clients then that's going to kill any benefit of > caching. I'd be curious just how much faster caching makes the > database access in the current case. Not necessarily. It's not as efficient to have multiple caches, but if they are used for different purposes, this probably isn't horrible either. If you think about web caching in general, having two squids on one apache is often useful :) > So, if MK is the moderator through which all requests have been made, > is it as good a moderator as the database itself? Part of this answer is database dependent. Certainly some are much better moderators than others :) > Anyway, that's where I am myself. There's other similar things to MK, > but most of them are lame dictionary interfaces (which capture the > easy 90% of the problem, but just make the other 10% of SQL queries > more awkward). I've looked at PyDO a little myself (it's part of > SkunkWeb), but haven't come to any opinion. The author talks about > some of these issues more or less in the intro to PyDO. I think there are at least two purposes here that are possible mixed up in MiddleKit. One purpose is making database stuff easier. It certainly seems much easier to do stuff with MiddleKit than the manual way. Chuck has done a great job in this regard. Another purpose is managing these middle objects. In java, these are often managed in their own environment, usually implement RMI, and can be distributed, etc. There's a lot more emphasis on caching, and how many copies are running, etc, and much less on making data access easier with the backend storage. I think MiddleKit just does both of these together, and I'm wondering if there's an easy way to seperate the functionality, so that I use my own storage stuff, but keep similar interfaces for the upper layer. I supposed I should just read through the code and see if I have any ideas. If I wasn't so used to the php/mysql/perl/blah way of doing web apps I probably would have used MiddleKit right off the bat. I may recode it to use that.. it certainly seems nicer. But for other things were the data might be shared, like this directory, I just need the middle layer without being so tied to the storage. /me goes to read code... jack. _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
