Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
On Fri, Jun 15, 2012 at 4:44 PM, Jeremy Nicoll - ml sourceforge jn.ml.sfrg...@letterboxes.org wrote: hakan hexi...@users.sourceforge.net wrote: should be solved by oneself ... Yes, if one has accepted a mature but inflexible product. But Mark has asked for comments on the way the package is being evolved, so I provided some. Hi Jeremy, I appreciate your comments and I did ask for comments. We seem to have 2 e-mail threads going here revolving around the same topic. I'm going to pull those 2 threads together here. As I understand you, you seem to think I should put a 3 into the objects names because the SQLite structs and APIs have a 3 in their name. I don't think that is needed. For a number of reasons. The main reason is, there are no other objects that the current names conflict with. The whole thing is moot. If at some future point in time there is some feature or enhancement in SQLite being added to ooSQLite that requires a similar but incompatible object, then that object will be introduced with a new name. And that just sums it up, there is no need for a 3 in the class names. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
On Sat, Jun 16, 2012 at 11:16 AM, Mark Miesfeld miesf...@gmail.com wrote: On Fri, Jun 15, 2012 at 4:44 PM, Jeremy Nicoll - ml sourceforge jn.ml.sfrg...@letterboxes.org wrote: hakan hexi...@users.sourceforge.net wrote: should be solved by oneself ... Yes, if one has accepted a mature but inflexible product. But Mark has asked for comments on the way the package is being evolved, so I provided some. Hi Jeremy, I appreciate your comments and I did ask for comments. We seem to have 2 e-mail threads going here revolving around the same topic. I'm going to pull those 2 threads together here. As I understand you, you seem to think I should put a 3 into the objects names because the SQLite structs and APIs have a 3 in their name. I don't think that is needed. For a number of reasons. The main reason is, there are no other objects that the current names conflict with. The whole thing is moot. If at some future point in time there is some feature or enhancement in SQLite being added to ooSQLite that requires a similar but incompatible object, then that object will be introduced with a new name. And that just sums it up, there is no need for a 3 in the class names. And indeed, you could also just change the name of the file used for ::requires and keep the names the same. That would allow for a pretty seamless upgrade path and it would still coexist with other programs that used a different version. Rick -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
Rick McGuire object.r...@gmail.com wrote: And indeed, you could also just change the name of the file used for ::requires and keep the names the same. That would allow for a pretty seamless upgrade path and it would still coexist with other programs that used a different version. I realise that it's possible that my questions make sense to me (but not, it seems, to you) because I don't properly understand all the ins and outs of the oo stuff. Also the issue is perhaps really a wider one for how ANY extension should be designed, not just the SQLite one, but this is the first such thing I've seen discussed here since joining this mail list. If one has two versions of the ooSQLite DLL and ooSQLite.cls installed, but given separate names (as I outlined earlier), I would expect there would be no problem if one user exec ::requires 'ooSQLite123.cls' and one had altered whatever it is within that cls file which specifies ooSQLite.dll and changed it to specify ooSQLite123.dll, and a second user exec ::requires 'ooSQLite456.cls'(altered to use ooSQLite456.dll) but what happens then if a single user exec has ::requires 'ooSQLite123.cls' ::requires 'ooSQLite456.cls' - if you want in that exec to use several databases, but more than one version of the SQLite engine? How do you code the connection request (or any other method etc) and specify that it goes to the right set of class definitions and hence the right dll? If that's not possible, would you be able to achieve it by encapsulating all SQLite123 processing in one subroutine (with one ::requires) and all SQLite456 processing in a second subroutine (with the other ::requires)? -- Jeremy Nicoll - my opinions are my own -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
Mark Miesfeld miesf...@gmail.com wrote: If the ooSQLite package gets included in the ooRexx distribution then an application written that uses ooSQLite will run on any system where the user of the application has ooRexx installed. And the user will not have to install anything else. But hopefully there's some way that the user can choose to install something else - a different build of whatever binary you provide, that has a different SQLite build inside(*) it? * - if it is statically linked 'inside' your binary? Or are you allowing a named DLL to be loaded by your interface code? I know from reading the SQLite users mail list - though I've not yet used SQLite for anything - that some users also make custom builds of SQLite themselves (see compile flags at http://www.sqlite.org/compile.html ). I would expect that if someone was using a custom-built SQLite binary for some application they'd want to be able to include it or build an equivalent into an instance of the ooRexx SQLite package, if they wanted to use ooRexx as part of that application. -- Jeremy Nicoll - my opinions are my own -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
On Fri, Jun 15, 2012 at 8:17 AM, Jeremy Nicoll - ml sourceforge jn.ml.sfrg...@letterboxes.org wrote: Mark Miesfeld miesf...@gmail.com wrote: If the ooSQLite package gets included in the ooRexx distribution then an application written that uses ooSQLite will run on any system where the user of the application has ooRexx installed. And the user will not have to install anything else. But hopefully there's some way that the user can choose to install something else - a different build of whatever binary you provide, that has a different SQLite build inside(*) it? Well sure. All the ooSQLite package consists of is: 06/15/2012 07:33 AM39,650 ooSQLite.cls 06/15/2012 09:05 AM 779,264 oosqlite.dll If the user wanted to use a different version of ooSQLite then they could replace those files with the version they wanted. Or they could put the different version files some place in the path ahead of those. Or use any other mechanism people use in this type of scenario. On SourceForge we are keeping prior release builds. So some time in the future there might be: ooSQLite.1.0.0 ooSQLite.1.1.0 ooSQLite.2.0.0 and so on. If some one was using ooSQLite.2.0.0 and wanted to go back to 1.0.0, they could just go to SourceForge and download the ooSQLite.1.0.0 package. * - if it is statically linked 'inside' your binary? Or are you allowing a named DLL to be loaded by your interface code? Right now it is statically linked. In the future I might set up a build that links dynamically to the SQLite library. But, I don't see a big need for that at this point. The only advantage, to the user, would be if ooSQLite was stuck at version 3.2.0 of SQLite and the current version of SQLite was 3.55.0, then the user could upgrade the SQLite DLL on their system and be using the most current version of SQLite. I don't foresee that being the case at this point. If / when it becomes a problem, I'll make a version of ooSQLite that links dynamically to SQLite. And, I'll most likely set up a build that links dynamically to SQLite some time in the future when I don't have anything better to do. I know from reading the SQLite users mail list - though I've not yet used SQLite for anything - that some users also make custom builds of SQLite themselves (see compile flags at http://www.sqlite.org/compile.html ). I would expect that if someone was using a custom-built SQLite binary for some application they'd want to be able to include it or build an equivalent into an instance of the ooRexx SQLite package, if they wanted to use ooRexx as part of that application. ooSQLite is very easy to build from source. The type of person that would have their own custom-built SQLite binary would simply check out the ooSQLite source and build their own version of ooSQLite. This option is always available, even if you don't want a custom build of SQLite. Just as /hex did, he built from source so he could try the online backup API before I had really even finished it. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
No offense, but... Isn't it great that someone take their time to implement the interface to SQLite when oneself is not talent/or lack the knowledge how to do it !. If SQLite will evolve and that is delayed/not implemented in ooSQLite, well you can always do the implementation yourself, but as I see it, you can't demand that it should be incorporated in ooSQLite. That kind of support normally is something one have to pay for, so building a commercial ooREXX application with ooSQLite, one can't demand anything from the developers of ooREXX/ooSQLite. The developed application is one owns responsibility and any demands should be solved by oneself or just accept the current status of the ooREXX/ooSQLite.. As English is not my native language, I don't want to argue, just to give some of my thoughts. I think ooREXX/ooSQLite/ooDialog is a great piece of software and are very satisfied with it. Great work ! /hex - Ursprungligt Meddelande: Från: Jeremy Nicoll - ml sourceforge jn.ml.sfrg...@letterboxes.org Till: oorexx-devel@lists.sourceforge.net Kopia: Datum: fredag, 15 juni 2012 17:17 Ämne: Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ? Mark Miesfeld miesf...@gmail.com wrote: If the ooSQLite package gets included in the ooRexx distribution then an application written that uses ooSQLite will run on any system where the user of the application has ooRexx installed. And the user will not have to install anything else. But hopefully there's some way that the user can choose to install something else - a different build of whatever binary you provide, that has a different SQLite build inside(*) it? * - if it is statically linked 'inside' your binary? Or are you allowing a named DLL to be loaded by your interface code? I know from reading the SQLite users mail list - though I've not yet used SQLite for anything - that some users also make custom builds of SQLite themselves (see compile flags at http://www.sqlite.org/compile.html ). I would expect that if someone was using a custom-built SQLite binary for some application they'd want to be able to include it or build an equivalent into an instance of the ooRexx SQLite package, if they wanted to use ooRexx as part of that application. -- Jeremy Nicoll - my opinions are my own -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
hakan hexi...@users.sourceforge.net wrote: No offense, but... and none taken. Isn't it great that someone take their time to implement the interface to SQLite when oneself is not talent/or lack the knowledge how to do it !. Yes, absolutely. If SQLite will evolve and that is delayed/not implemented in ooSQLite, well you can always do the implementation yourself, No, I can't. Before this package was announced I was already investigating SQLite with a view to using it via a command line interface, but I certainly don't have the skills needed to integrate it with ooRexx. but as I see it, you can't demand that it should be incorporated in ooSQLite. I'm not /demanding/ anything. But it seems to me that extending ooRexx's capabilities to include SQLite is a BIG thing, bearing in mind just how much SQLite is used. That should mean that the package is attractive to people who may use it in production situations... but that also means those users may have greater expectations of the ease with which - say - apps using it can readily change from one version of SQLite to another, or run using both versions in parallel for (say) regression testing. If we want ooRexx's capabilities to be taken seriously then significant packages like this should be designed to support proper use and testing of apps that use it. That kind of support normally is something one have to pay for, so building a commercial ooREXX application with ooSQLite, one can't demand anything from the developers of ooREXX/ooSQLite. I'm not suggesting anyone should support an app written in ooRexx SQLite. SQLIte support is provided elsewhere anyway. I am however suggesting that some thought should be given to the real life requirements of users of such a package. The developed application is one owns responsibility and any demands should be solved by oneself ... Yes, if one has accepted a mature but inflexible product. But Mark has asked for comments on the way the package is being evolved, so I provided some. -- Jeremy Nicoll - my opinions are my own -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
Op 05-jun-12 schreef Mark Miesfeld: On Mon, Jun 4, 2012 at 4:20 PM, Lee Peedin l...@safedatausa.com wrote: SQLite pretty much indicates a DB is involved. I'd suggest simply ooSQLiteConn or even better IMHO ooSQLiteConnection. Hi Lee, I like using Connection rather than Conn myself. -- Mark Miesfeld My suggestion would be : ooSQLDBConnection leaving the database package open so that one day a clever developer will supply the connection to the freely available DB2 Express-C -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
On Wed, Jun 6, 2012 at 11:58 AM, Klaas. kpli...@xs4all.nl wrote: Op 05-jun-12 schreef Mark Miesfeld: On Mon, Jun 4, 2012 at 4:20 PM, Lee Peedin l...@safedatausa.com wrote: SQLite pretty much indicates a DB is involved. I'd suggest simply ooSQLiteConn or even better IMHO ooSQLiteConnection. My suggestion would be : ooSQLDBConnection leaving the database package open so that one day a clever developer will supply the connection to the freely available DB2 Express-C Hi Klass, Good to hear from someone other than the regulars. ooSQLite is a very database specific package, rather than a general purpose SQL package. So, there would not be a way to change the connection to DB2, or MySQL, etc.. In the incubator we have a general purpose SQL package: orxsql I think you could use that to connect to DB2. One idea I have for the future would be to create several database specific ooRexx packages. Then create a package, say RexxDatabase, where you could specify which database specific package the RexxDatabase object would use. But, I don't know if I'd ever get to that in my life time. Then Jon could use RexxDatabase with the ooMySql backend I could use RexxDatabase with the ooSQLite backend, and you could use RexxDatabase with the ooDB2 backend One reason I started a SQLite specific package is that the database engine itself is easily embedded in the ooRexx package. This gives the ooRexx programmer a convenient package to use with a light-weight database engine that doesn't need anything else. It doesn't need MySQL or DB2 to be installed, or configured, or administered on the system. If the ooSQLite package gets included in the ooRexx distribution then an application written that uses ooSQLite will run on any system where the user of the application has ooRexx installed. And the user will not have to install anything else. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
SQLite pretty much indicates a DB is involved. I'd suggest simply ooSQLiteConn or even better IMHO ooSQLiteConnection. Lee Sent From My iPhone On Jun 4, 2012, at 6:58 PM, Mark Miesfeld miesf...@gmail.com wrote: Hi, In anticipation that a higher level abstraction of a database class will be added to ooSQLite and since the ooSQLiteDB class is really a database connection rather than a database, I'd like to change the name of the class before I get to much written. My first thought was ooSQLiteDbConn for a database connection. But, it could be ooSQLiteDbConnection. However, that is starting to get a little long. Or, it could be ... ? Any thoughts? I'd rather not change the class name a third time, ;-) although Slick Edit does global find and replace very well. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooSQLiteDB name change to ooSQLiteDbConn or ?
On Mon, Jun 4, 2012 at 4:20 PM, Lee Peedin l...@safedatausa.com wrote: SQLite pretty much indicates a DB is involved. I'd suggest simply ooSQLiteConn or even better IMHO ooSQLiteConnection. Hi Lee, I like using Connection rather than Conn myself. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
