On 10/8/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > Jorge Vargas wrote: > > On 10/8/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > >> I have decided to not use SqlObject [1]. > >> > >> What the project should possibly do: > >> > >> * Create a new mailinglist (e.g. on Google Groups), thus the > >> spam-problem is reduced. The new groups should of course still be > >> available with the nntp interface (gmane). This step enables > >> _communication_ around SQLObject. (SQLAlchemy has recently moved to > >> google groups and I assume the would assist this project with this step). > >> > > I agree with that googlegroups is great at filtering spam. > > ok > > >> * The remaining developers should focus to provide an sqlobject API > >> compatibility layer for SQLAlchemy. This way existent software can > >> migrate without many effort. I am sure that some projects would provide > >> support for this (SQLAlchemy itself, TurboGears). > >> > > I don't see why > > #1 SQLObject2 will provide much of the stuff SA currently does. > > SQLObject2 is even more inactive: > > http://www.webwareforpython.org/archives/message/20060223.053837.bacf323d.en.html > > http://sqlobject.org/2/ > then get the code and start working on it.
> > #2 this "layer" already exists and it's call active mapper which is in SA > > trunk. > > I don't think it's API compatible with SQLObject. > it's goal is to emulate SO-like interfaces. of course it can't be 100% because the underlaying layer is not SO > But of course developers could contribute to this, too. > > >> * The project should move away from sourceforge. Trac provides nice > >> functionality for small to medium scale open source projects. > >> > > yes and you need to host it. I don't see why sf is so bad, I use trac > > for my stuff but that's me. > > I (and many other's, including the python foundation) seem to see them. > then provide a trac for SO, I don't see why trac is so important vrs SF, it's a matter of taste. > >> * At a minimum, the project should inform potential users about the low > >> activity on the SQLObject project. > >> > > Honestly I don't see why SO is "low activity" at the moment all the > > features it's supposed to have are there and working. > > An ORM for a dynamic language without schema evolution support? > actually who doesn't supports dynamic language schema evolution is the underlaying DBs, on the other hard SO can add and remove cols at runtime, it is not the best thing I have to admit but it's there. I seems to me that you only know SO from it's integration to TG, and at that point your right from TG perspective the only way to change the db schema is tg-admin sql drop && tg-admin sql create. > Additionally, please review the statements of some team members within > this thread: > > http://thread.gmane.org/gmane.comp.python.sqlobject/6910/focus=6910 > that is what you get went a project has more people using it then maintaining it. > >> The project lead should of course support all this moves. > >> > > man... I just wasted my time, take a look at > > http://en.wikipedia.org/wiki/Ilias_Lazaridis > > I see. > and looking at the TG thread it seems you made quite a reputation on the django list. > Hopefully the project-lead makes the right steps to save the (ptential) > userbase from future trouble. > I don't want to know what that means Removed spam > sqlobject-discuss mailing list > sqlobject-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
