Cross platform search database
Hi, I would like to build a cross platform app that would be shipped on a CD-ROM that contains a whole collection of html files. Previously, we had to depend on a Java applet, but that had all sorts of problems with XP and also OS X and works on certain browsers only. I would like to abandon that and use Revolution as the engine if possible. My question is this: What would be the best approach to building this? I did have some preliminary code to recursively decend down a series of folders and then the general idea would be to load up the text into cards and allow text searching on those cards? My understanding from some of the previous discussions is that the entire stack is loaded into memory and that would mean that the more content there is, the more memory would be required for that. Are there any other approaches to this? Can a stack keep most of its data on the hard disk and still be searchable for its text? I don't have a problem with keeping the redundant text inside Revolution stacks. My goal in the long term is to do away with the html files totally (lots of legacy files) and to have everything presented from within Revolution itself. The goal is to allow text searching, which will show up a bunch of hits in a window and a scrolling list and then allow the user to click on one of those choices and then launch back into the browser window to see the actual file. I would appreciate it if there are any pointers or suggestions as to how to best go about doing this. In the old days of Hypercard and Supercard, it would have been a matter of just throwing everything into individual cards on a stack and the stack contents are paged from the hard drive. If everything is preloaded into memory in Revolution, then I might have a problem ultimately as the contents grow before I am able to make a full transition a cd-rom that's entirely done using Revolution. Jesse Sng ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Cross platform search database
Hi Jesse! > I would like to build a cross platform app that would be > shipped on a CD-ROM that contains a whole collection of html files. We'll see about that! I'll give you another approach list that could maybe fit... > Previously, we had to depend on a Java applet, but that had > all sorts of problems with XP and also OS X and works on > certain browsers only. > I would like to abandon that and use Revolution as the engine > if possible. Very good choice! You'll see that you can go beyond HTML in no time without much trouble and better results just like in the old days! > My question is this: What would be the best approach to building this? Since HyperCard, the stack is the dataholder and the application. This is one approach. The other which is the application accessing the data stored externally is the lighter approach. Memory isn't usually a problem but oversized stacks can be. So you can easily create a GUI to browse through the folders and load the data from text files. I find it easier to grab data off stack files (which can be encrypted and loaded hidden!) It all depends on the data... > I did have some preliminary code to recursively decend down a > series of folders and then the general idea would be to load > up the text into cards and allow text searching on those cards? Well, if the stack has the text files imported, you wont need to reload them after. A stack is also very easy to search... > My understanding from some of the previous discussions is > that the entire stack is loaded into memory and that would > mean that the more content there is, the more memory would be > required for that. The optimal size depends on the granularity of your data. Lots of records or huge records or both? Lots of searching "what?" You can always index stack content and distribute it like a linked list or double linked list record database (you keep a link to a card in a stack and that's a link! This is really fast for multi leveled records or hierarchical databases. Imagine you have a dictionary or encyclopedia. You can't put it all in one stack! So you can break it down into subjects or alphabetical groupings or usage frequency or by geographical / ethimological source! > Are there any other approaches to this? Can a stack keep most > of its data on the hard disk and still be searchable for its text? Yes. Yes! But I would keep images separated... If there's over a hundred images, keep them off-stack with the relative path to the image. You can ammend the real path at runtime or preload the images into the stack you display - choices are infinite... > I don't have a problem with keeping the redundant text inside > Revolution stacks. My goal in the long term is to do away > with the html files totally (lots of legacy files) and to > have everything presented from within Revolution itself. no prob. RunRev apps run locally or off the pc without installers. I would assume the same from Macs or Linux but not sure as I've not tried them yet. > The goal is to allow text searching, which will show up a > bunch of hits in a window and a scrolling list and then allow > the user to click on one of those choices and then launch > back into the browser window to see the actual file. > I would appreciate it if there are any pointers or > suggestions as to how to best go about doing this. There's at least a million stacks out there with examples of databases. Lots of links to show... But I can proudly say you can find examples for all you want in monsieurx.com. You have HTML parsers - the DiscreteBrowser stack You have databases - Search for csv (a simple csv file importer with field parser to create a stack database. Or search for xos an advanced virtual database meta-format OS. There's an example self documenting of sorts stack too... > In the old days of Hypercard and Supercard, it would have > been a matter of just throwing everything into individual > cards on a stack and the stack contents are paged from the > hard drive. If everything is preloaded into memory in > Revolution, then I might have a problem ultimately as the > contents grow before I am able to make a full transition a > cd-rom that's entirely done using Revolution. Still is actually! Just with mo features to throw at the client! Cheers Xavier ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Cross platform search database
The easiest way to set up all of the searching, etc. for a large database would be to store all of the data in an SQL database and let the database server worry about indexing, searching, and sorting results; however, this would require there to be an SQL database server running on the machine in order to query the results. Not a particularly nice thing for running such a program from a CD. However, there is also the possibility of an *embedded* database server, which would place a miniature database server into your application. I have personally not tried using one of these, but it may be worthwhile for you to research one. Rev supports one called "Valentina" (spl?), the advantage of this approach is that you get the search and sort capabilities of a database server, the database engine handles the disk-to-RAM issues for you, and there is still nothing for the end-users to install: the database server would run inside your created standalone application with no network access or anything to worry about, and all of the data gets stored in a file on your CD. It would be completely transparent for your end users, and simplify your life considerably. On Dec 4, 2004, at 9:59 AM, MisterX wrote: Hi Jesse! I would like to build a cross platform app that would be shipped on a CD-ROM that contains a whole collection of html files. We'll see about that! I'll give you another approach list that could maybe fit... Previously, we had to depend on a Java applet, but that had all sorts of problems with XP and also OS X and works on certain browsers only. I would like to abandon that and use Revolution as the engine if possible. Very good choice! You'll see that you can go beyond HTML in no time without much trouble and better results just like in the old days! My question is this: What would be the best approach to building this? Since HyperCard, the stack is the dataholder and the application. This is one approach. The other which is the application accessing the data stored externally is the lighter approach. Memory isn't usually a problem but oversized stacks can be. So you can easily create a GUI to browse through the folders and load the data from text files. I find it easier to grab data off stack files (which can be encrypted and loaded hidden!) It all depends on the data... I did have some preliminary code to recursively decend down a series of folders and then the general idea would be to load up the text into cards and allow text searching on those cards? Well, if the stack has the text files imported, you wont need to reload them after. A stack is also very easy to search... My understanding from some of the previous discussions is that the entire stack is loaded into memory and that would mean that the more content there is, the more memory would be required for that. The optimal size depends on the granularity of your data. Lots of records or huge records or both? Lots of searching "what?" You can always index stack content and distribute it like a linked list or double linked list record database (you keep a link to a card in a stack and that's a link! This is really fast for multi leveled records or hierarchical databases. Imagine you have a dictionary or encyclopedia. You can't put it all in one stack! So you can break it down into subjects or alphabetical groupings or usage frequency or by geographical / ethimological source! Are there any other approaches to this? Can a stack keep most of its data on the hard disk and still be searchable for its text? Yes. Yes! But I would keep images separated... If there's over a hundred images, keep them off-stack with the relative path to the image. You can ammend the real path at runtime or preload the images into the stack you display - choices are infinite... I don't have a problem with keeping the redundant text inside Revolution stacks. My goal in the long term is to do away with the html files totally (lots of legacy files) and to have everything presented from within Revolution itself. no prob. RunRev apps run locally or off the pc without installers. I would assume the same from Macs or Linux but not sure as I've not tried them yet. The goal is to allow text searching, which will show up a bunch of hits in a window and a scrolling list and then allow the user to click on one of those choices and then launch back into the browser window to see the actual file. I would appreciate it if there are any pointers or suggestions as to how to best go about doing this. There's at least a million stacks out there with examples of databases. Lots of links to show... But I can proudly say you can find examples for all you want in monsieurx.com. You have HTML parsers - the DiscreteBrowser stack You have databases - Search for csv (a simple csv file importer with field parser to create a stack database. Or search for xos an advanced virtual database meta-format OS. There's an example self documenting of sorts stack too... In the old days of Hypercar
Re: Cross platform search database
> The easiest way to set up all of the searching, etc. for a large > database would be to store all of the data in an SQL database and let > the database server worry about indexing, searching, and sorting > results; however, this would require there to be an SQL database server > running on the machine in order to query the results. Not a > particularly nice thing for running such a program from a CD. Or just do it all in a Filemaker runtime. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Cross platform search database
Or use the Valentina SQL engine for heavy lifting, which ships with Rev. The easiest way to set up all of the searching, etc. for a large database would be to store all of the data in an SQL database and let the database server worry about indexing, searching, and sorting results; however, this would require there to be an SQL database server running on the machine in order to query the results. Not a particularly nice thing for running such a program from a CD. Or just do it all in a Filemaker runtime. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
