Menu
▾
▴
plnet-discuss — Open discussion about PLNet.org
You can subscribe to this list here.
| 2001 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael O'N. <cle...@ho...> - 2003-04-16 22:50:23
|
Bill, I got absolutely zero feedback on my propositions for the PLNet RPM-thingie. Wasn't expecting much at all, got even less. Maybe I need to shower more often... Anyway, a couple of things have changed for the PL/SQL CodeBrew project and myself in general, and some of those changes relate to PLNet. For a variety of reasons, it has become imperative that I construct an RPM-like tool to distribute my open source, shrinkwrap and custom software ASAP. I have constructed a fair amount of it to date. It is python based. It is essentially an ultra-lightweight web server, with a suite of python scripts executed as cgi's. The reason they are executed as cgi's and not via command prompt is that I then have access to build HTML interfaces. #1 I have not built anything with PLNet's needs directly in mind, but I think it will useful to PLNet nonetheless. #2I don't have anything I'm willing to share yet, but I will very soon (eta: end of April) #3 I plan on distributing it via the PL/SQL CodeBrew project (version 1.0), I'll leave it to your discretion to begin co-opting it or not. I'll shoot you an email again, when CodeBrew version 1.0 is released! Michael _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: Michael O'N. <pub...@cl...> - 2003-03-02 07:54:10
|
Here's my latest thoughts on the PLNet Client component: = http://plcodebrew.sourceforge.net/wiki/index.php?page=3DPLNetStuff It's a wiki page so feel free to comment on and edit as needed. Michael |
|
From: William L. P. <bi...@da...> - 2003-02-28 23:58:00
|
Michael, On Sat, Feb 22, 2003 at 10:41:14AM -0600, Michael O'Neill wrote: > ...snip... > > Obviously, I'm leaning heavily towards a Python implementation. Bill, Do > you forsee any major problems in doing so? Since I can't even spell Python, I'm probably not the right guy to ask. I would just hope that it can be installed easily by the average Oracle programmer -- maybe even bundled into the PLNet client installer. Maybe somebody else on the list has some relevant experiences... Thanks Bill |
|
From: Michael O'N. <pub...@cl...> - 2003-02-22 16:44:16
|
I've been weighing the merits and weaknesses of applying the available = technologies to the task of developing the PLNet CLient. PLNet Domain Glossary: PC PLNet Client software PR PLNet Repository User PLNet end user Title PLNet software SQL*Plus ------------------------------------------------------------ A combination of a PR-generated SQL*Plus script and PLNet-specific = stored procedures in User's database would be utilized to = download/install/upgrade Titles. Merits a.. Nearly absolute availability on all Users platforms. b.. Nearly absolute ubiquity of installation on all Users on Users' = systems. c.. Would function extremely uniformly for all Users. Weaknesses a.. User interaction options via SQL*Plus is extremely minimal. b.. Almost all User interactivity with the PC processes would have to = occur at the PR tier. c.. Significant dynamic html GUI would be needed at PR tier (not at = all desirable). d.. Significant PLNet-originated stored procedures would be needed in = the User's database. Python ------------------------------------------------------------ A program modeled in functionality extremely similar to Cygwin's = installer. Users would interact with the PC to download/install/upgrade = Titles. Merits a.. Python interpeter is available and stable on most User platforms. b.. Python interpeter is easy to install and maintain. c.. Rich interface could be built with Tk and/or curses. d.. No significant PLNet-originated stored procedures would be needed = in the User's database. e.. No significant PR GUI needed. f.. I'm extremely interested in learning this relatively simple = language; this is a great excuse. Weaknesses a.. Requires properly-versioned Python interpreter to be installed by = User. b.. Program would be somewhat complex to handle the User interaction = and Title-related tasks. c.. I'm not a Python expert (even less so with Tkinter module), so = support will be spotty. Java ------------------------------------------------------------ A program modeled in functionality extremely similar to Cygwin's = installer. Users would interact with their PC to = download/install/upgrade Titles. Merits a.. JRE is available and stable on most User platforms. b.. Extremely rich interface could be built. c.. No significant PLNet-originated stored procedures would be needed = in the User's database. d.. No significant PR GUI needed. Weaknesses a.. Requires properly-versioned JRE/SDK to be installed by User. b.. Program would be somewhat complex to handle the User interaction = and Title-related tasks. c.. Java is an overly complex tool for the task, and I mostly hate = working with Java. d.. Much support would be needed (as all Java apps do) and I would = never want to give it. A couple of honorable mentions: PL/SQL Gateway (mod_plsql) - greatest feature/functionality = possibilities, but too much setup and support to be useful as a simple = universal tool; bulletproof liklyhood is nearly zero. A locally executing PHP web application - requires an installed and = properly configured apache and PHP installations, which also requires = too much setup to be useful as a simple universal tool. Research = indicates that PHP also functions differently enough across platforms to = be a problem. Obviously, I'm leaning heavily towards a Python implementation. Bill, = Do you forsee any major problems in doing so? Michael O'Neill P.S. I got my project's (plcodebrew) mySQL database setup by the SF = folks, installed the ultra-simple phpMyAdmin tool and have been = extremely pleased with the simplicity of working with my database. It's = not Oracle but still very nice. |
|
From: Michael O'N. <pub...@cl...> - 2003-02-13 03:15:07
|
Bill, Tell me what you think of this kernel of thought. Given: - my developer skills are highly concentrated in the area of server-side PL/SQL, and - the bulk of PLNet titles distributed will be server-side PL/SQL-centric and thus each PLNet user would, and - the client component should be as platform independent as Oracle's client software, then it seems to me that it is logical (and desirable) to me to cram as much of the smarts of the PLNet Client component into server-side PL/SQL. This PL/SQL would reside in the user's database (not in any PLNet database). We can assume the User has an Oracle database, can't we? Keep in mind that I completely agree with you that the PLNet Repository should be as simple as possible in data model and API. It should be completely unaware of what clients are accessing it - so that if someone comes along and wants to write a wonderful Java-based PLNet Client component, the repository would not have to be changed one iota. Here's an ultra-rough proposed scenario of how I see the interplay between the PLNet components: - The User - wants to install, upgrade, uninstall PLNet software titles - The PLNet Client (PC) - the locally installed PL/SQL that generates and executes all PLNet software title installation, upgrade and uninstallation - SQL*Plus - Invokes PC - The PLNet Repository (PR) - the webserver and database tiers that the User (interactively) and the PC (machine-to-machine) invoke - can be as mirrored and distributed as necessary - The PLNet Authority (PA) - the database tier that spawns all PRs The PA is constructed by any means necessary. It is initially (and for the forseeable future) housed at Bill Prybl's house. The only interactive user is Bill Prybl. It's sole purpose is to keep track of all PLNet titles and interdependencies. The PA can be a 9i Database or a piece of loose leaf paper. The PA has a one stable interaction with the outside world: a procedure that spits out the scripts neccessary to re-constitute a mySQL database (something that is fairly straightforward) which makes up the database tier of the PR. Potential Users download and install PC in a manner similar to most conventional PL/SQL modules via SQL*Plus. The PC is probably installed in a highly privileged schema - though PLNet software titles needn't be. The initial and only PR would be hosted on SourceForge. The PR database is accessed by an extremely limited set of PR CGIs (in Python, etc) that present a GUI for Users to submit to the PR: #1 what they want and #2 what they have. #2 includes the locally installed PLNet software titles and their versions installed as well as the version of the PC itself - as it must be current enough to the interact with the PR. A straightforward function of the PC is to generate an XML document that represents aspect #2, which can simply be pasted into an HTML form (or eventually submitted machine-to-machine). After evaluating #1 & #2 the PR returns an XML document or a SQL*Plus script, which represents the "instruction set" that the PC needs to know (this nugget needs lots more clarity,) that the User submits back to his PC by SQL*Plus. The PC then interacts directly with the PR (machine-to-machine), fetching what it needs from the PR and compiling/executing what it should, handling all the intracies and exception handling of such an operation. That's it in a nutshell. There are a number of advantages to my proposed architectural scenario that are critical and would probably have to be substituted in kind in any alternate architecture: - The PC GUI is SQL*Plus, which is a remarkable savings in time and effort (read: my time, my effort) - The PC GUI is SQL*Plus, which is ubiquitous to all Users (read: Even though I could become proficient in Java or Python, I don't want to support a publicly distributed application in such a platform) - Of all the components, the only 24/7 worker bee, the PR, is hosted by SourceForge which is highly available, heavily bandwithed and free (read: I'm cheap for so many reasons) - The PR is distributable enough so that a User may maintain his own PR if needed due to firewall restrictions - because the PC must communicate with the PR directly which is the most vital (IMHO) as it gives us the most access to the PL/SQL functionality that we are all interested in using in the first place. - I already have a significant chunk of what the PC coding done (read: this is where I can make CodeBrew shine as something meaningful) Let me know what you think. Michael |
|
From: Nagrath P. (Intranet) <PS...@ko...> - 2002-04-26 04:05:28
|
Hi all,
I am a Java programmer who has got this assignment where I have to
keep polling a table for new records. Identification of new records is done
through a col where flag is maintained. My problem is that the polling has
to be done every hour and if new record is found, I have to start a process.
How can I make this process run every hour where this table is polled and
checked for new records ? In java we can do it easily through
multi-threading. Any help is appreciated.
Thanks in advance.
Prem Sagar
----------------------------------------------------------------------------
CONFIDENTIALITY/PROPRIETARY NOTE.
The document/s accompanying this electronic transmission contains
information from Kirloskar Oil Engines Limited, which is confidential,
proprietary or copyrighted and is intended solely for the use of the
individual or entity named on this transmission. If you are not the intended
recipient, you are notified that disclosing, copying, distributing or taking
any action in reliance on the contents of this information is strictly
prohibited. This prohibition includes, without limitation, displaying this
transmission or any portion thereof, on any public bulletin board. If you
are not the intended recipient of this document, please return this document
to Kirloskar Oil Engines Limited immediately.
----------------------------------------------------------------------------
"Please visit us at <http://www.kirloskars.com>".
|
|
From: Bill P. <bi...@da...> - 2001-02-20 19:32:36
|
Hi again, Well, since I got absolutely no response to my last email (dated 6 Feb, subject: "status of PLNet), I'm thinking that either (1) the mail server messed up and forgot to send it, or (2) nobody had anything to say. In case it's (1), I am resending (see attachment). In case it's (2), I have decided that I'm going to introduce a *very* low-tech catalog page before trying to do anything too fancy. Please look at http://plnet.org/catalog.html and send me your criticisms. Initially I want this to be really bare bones so that I don't have to keep up with version numbers and release dates and such. Please note that this is a DEMO ONLY, there are only a few things listed. I don't yet have an approach to ordering the different categories. Hey, for that matter, I don't even have a list of categories yet. Thanks Bill -- ______________________________________________ http://www.datacraft.com/ http://plnet.org/ |
|
From: Bill P. <bi...@da...> - 2001-02-06 15:13:09
|
To folks interested in PL/SQL sharing: I got a private email from someone on the list who asked about the status of PLNet and I thought I should respond to everybody. Hopefully this will spark some wider discussion and maybe even some forward movement! My sense is that the most important thing to do up front is establish the way that we are going to catalog metadata that describes reusable PL/SQL code. If at all possible, we should use an existing method for expressing and storing this metadata, instead of inventing something new. There are a number of related initiatives under way that are designed to catalog various web-based and/or software resources. These include: Dublin Core Metadata Initiative m e t a l a b open source metadata framework Association of Shareware Professionals' "PAD" Open Software Description Specification (probably not a good fit) www.rpm.org (probably not a good fit, but interesting) Does anyone on the list happen to have any experience with these? The major benefit of going this route is that more general-purpose tools could be employed in the management and use of the repository, instead of writing a ton of custom repository management code. Unfortunately, I don't know whether any of the existing schemes are yet up to the task. In any case, we will almost certainly need to write at least some custom code. Also, I think there could be a big benefit to having a completely distributed repository but a centralized directory. In other words, people with code to share could put it on any convenient web server, and announce it to the directory machine(s), which would have a "spider" that would crawl the known sites to collect the metadata. Comments? Thanks Bill PS To answer the question "why is this moving so slowly," there is probably no one to blame but me. I've been busy with a book manuscript that is sort of overdue at the publisher. I guess the good news is there is still some level of interest in the community; every week or so a new subscriber signs up for one of the email distribution lists. ______________________________________________ http://www.datacraft.com/ http://plnet.org/ |
|
From: Lakshmanan K. <lak...@us...> - 2001-01-19 18:32:43
|
I have two questions How do I generate an Oracle report from inside a PL/SQL code? And how do I prompt an user input from inside a PL/SQL code? -lakshmanan ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D= 1 |
1 message has been excluded from this view by a project administrator.
