OT: RE: Upload and retrieval of stories? [CF-Talk]
download the demo and if you don't mind the "Trial Softmare" message, Softmare! _Excellent_ new word! Having one myself coding in Perl right now ::( Nick ** Information in this email is confidential and may be privileged. It is intended for the addressee only. If you have received it in error, please notify the sender immediately and delete it from your system. You should not otherwise copy it, retransmit it or use or disclose its contents to anyone. Thank you for your co-operation. ** -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
Chris; This problem is exactly what we have built a solution for in publishing Spank! Youth Culture Online (http://www.spankmag.com). We are also beginning to market the engine as a product called Lopedia. There are several fields for each entry - but importantly, we strip out all HTML and ASCII for submitted material (security reasons) and replace with a pseudo-code that we parse back with each story (submit a response to a thread - there's a link that shows all the pseudo-code). This way, we can change the parser to modify the look and feel of the text. This is also how we have the first word of each paragraph in the Spankopedia section (not the forums) Bold and +1 size. We are slowly moving over 350 old, full length features into the database from raw HTML files. Let's just say - If I had these in a database to begin with (OK - we started back in 1995), I would be a much happier boy. One thing though - I don't use fusebox and don't like the methodology all that well (OK - let the flames begin - you people do seem a little religious about dissenting voices), but it's a matter of personal choice. Do though DB it all. Right now. From the beginning. Stephen R. Cassady Publisher Cofounder, Spank! Youth Culture Online wb. http://www.spankmag.com em. [EMAIL PROTECTED] About Spankmag.com! - Launched 01 November 1995, Spank! Youth Culture Online is a flagship quality youth online-lifestyle magazine (http://www.spankmag.com), and the very first-ever of it's kind. Spank!s online services offer users cool reviews, informative features, opinions, contests, cartoons and areas to express their own thoughts and ideas. At the heart of Spank!s services is original, fresh, content built by a team of editors from North America and around the world. True to it's nature, Spank! leverages this talent into a peer to peer meeting of youth (14 - 26) from around the world. Free of censorship, open to ideas, Spank! weeds out the parental guidance side found in most youth journals designed by adults. Spank! is the playground and stepping stone for youth. For more information please contact us directly @ Stephen Cassady, [EMAIL PROTECTED] Date: Sat, 16 Sep 2000 12:08:23 -0800 From: "Chris Lott" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Upload and retrieval of stories? Message-ID: 024e01c02019$de0a92c0$6401a8c0@S003817 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My new site is related to this thread, so I would like to hear suggestions about the following issues. The site is largely dedicated to serving out a selection of poems, essays, stories, etc. I am trying to bridge the gap between relatively easy contributions and adequate performance when serving the file (aren't we all?). 1) Should I store the text with HTML formatting? Most of the items will have formatting needs (bold, italic, explicit line breaks, and of course paragraph breaks) and short of some kind of custom shorthand, HTML seems like the best way. 2) How should I deal with the input and splitting of longer stories: should the user submit the html/text file and then I will have CF split the file into different database entries using some algorithm for a word count and then split at the nearest sentence or paragraph break or ?? 3) Could someone explain how I might create tables to handle the split text? Should I just have a single table with title, partnum, text and then when displaying check if there is more than one partnum, or should I have a couple of tables? I'm starting to wonder if I should do this with a db-driven site at all :) But I've already been tied to doing a CF site with Fusebox, though the methodology is largely irrelevant. c -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
Where? I couldn't find it. best, paul At 01:45 AM 9/17/00 -0600, you wrote: (submit a response to a thread - there's a link that shows all the pseudo-code). -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One thing though - I don't use fusebox and don't like the methodology all that well (OK - let the flames begin - you people do seem a little religious about dissenting voices), but it's a matter of personal choice. Do though DB it all. Right now. From the beginning. Thanks for the advice. I am working on a completely db driven solution as we speak. I'm not wedded to Fusebox, though I have found that it has helped me in many ways (being the disorganized kind of illiterate programmer that I am, having a method of any kind has been a boon!), it has also slowed me down in others, primarily because I think good beginner documentation is sparse, or at least good beginner documentation of the kind *I* need! c - -- Chris Lott -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 for message encryption and authentication: USE PGP! Comment: PGP KeyID: 0x51046CFD iQA/AwUBOcWqjtaLYehRBGz9EQIX1ACdEUsxiMIZDeO42AdM2sZRkIvSfgAAoMWX LaPRkp/T+qsh1o//vLVPI2Po =rC5Q -END PGP SIGNATURE- -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: Upload and retrieval of stories?
So, something does exist. Couldn't tell from the truespectra.com site much about the product. Got any general info you would share? Hardware req'ts? Software req'ts? NT or Win2K, lots of CPU and RAM. Runs as a service. Performance options available? (load balancing, clustering, etc.) No clustering built-in, but I'm sure you could do round-robin DNS or some such. To store images do they use: Native OS File system and/or database Native file system, with a pretty slick cache to RAM (you set the % of RAM to use) that writes itself to disk on service shutdown. An XML document gets written on the fly to manage the location of all the cached images (various resolutions, etc.). When a jpg, or gif, or png, or whatever image is served for the first time, it gets converted to FlashPix format for the cache... you see a CPU spike when that happens, then subsequent calls for the image don't even blip the CPU. Where are the images stored As regular files, with a mirror-image cache directory. Where is the Descriptive info (Title, Caption, attributes, etc.) Store If you're using FlashPix, that meta-info can be stored in the same file. Otherwise, you'll need to write your own db/CF management system. -Ron At 10:15 PM -0500 9/15/00, [EMAIL PROTECTED] wrote: At 8:37 PM -0400 9/15/00, Jon Hall wrote: Err this database already exists...I call it a file system. What would you dynamically change in an image? Changing the size of an image is already possible via the img tag. Changing resolution on the fly would require processing power that is way beyond capabilities today, not to mention the browsers dont support over 72x72... We integrate the TrueSpectra Accelerate dynamic image server (http://truespectra.com) with ColdFusion for applications like this: http://lookclose.com/slideshow/Ron/Kaori and the Java applet version: http://lookclose.com/zoomlet/Ron/Kaori Here's an example of an image URL (watch the line wrap): http://images.lookclose.com:/Demo/CrownGraphic/ACloseView.JPG ?wid=200cv t=jpeg Change the wid value to anything between 1 and 1000, and you'll see how quick the image server spits out the right size. It's not cheap, at $5K per CPU... but it sure performs and caches well. Ron Allen Hornbaker President/CTO Humankind Systems, Inc. http://humankindsystems.com mailto:[EMAIL PROTECTED] -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My new site is related to this thread, so I would like to hear suggestions about the following issues. The site is largely dedicated to serving out a selection of poems, essays, stories, etc. I am trying to bridge the gap between relatively easy contributions and adequate performance when serving the file (aren't we all?). 1) Should I store the text with HTML formatting? Most of the items will have formatting needs (bold, italic, explicit line breaks, and of course paragraph breaks) and short of some kind of custom shorthand, HTML seems like the best way. 2) How should I deal with the input and splitting of longer stories: should the user submit the html/text file and then I will have CF split the file into different database entries using some algorithm for a word count and then split at the nearest sentence or paragraph break or ?? 3) Could someone explain how I might create tables to handle the split text? Should I just have a single table with title, partnum, text and then when displaying check if there is more than one partnum, or should I have a couple of tables? I'm starting to wonder if I should do this with a db-driven site at all :) But I've already been tied to doing a CF site with Fusebox, though the methodology is largely irrelevant. c -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 for message encryption and authentication: USE PGP! Comment: PGP KeyID: 0x51046CFD iQA/AwUBOcPTLdaLYehRBGz9EQLN7ACfdD+BAqox51FmSnOgH4viyOCErlEAn3xH HC6gEKOqkWC7Sd0sIzORljjn =kDLa -END PGP SIGNATURE- -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: Upload and retrieval of stories?
On the subject of text, I believe all major browsers has an internal gzip decompressor with can deflate the compressed html stream from a web server. Which webservers compresses the outgoing streams? Is there an option in IIS that we can set or is this automatic? I'm just curious and would love to save some bandwith. IIS 5 supports this; you can configure it from the server's Master Properties dialog. I don't know how well it works, or whether it works with browsers other than IE, though. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
At 12:08 PM -0800 9/16/00, Chris Lott wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My new site is related to this thread, so I would like to hear suggestions about the following issues. The site is largely dedicated to serving out a selection of poems, essays, stories, etc. I am trying to bridge the gap between relatively easy contributions and adequate performance when serving the file (aren't we all?). 1) Should I store the text with HTML formatting? Most of the items will have formatting needs (bold, italic, explicit line breaks, and of course paragraph breaks) and short of some kind of custom shorthand, HTML seems like the best way. Unless you want to limit or control formatting and replace it with some meta-language, go ahead and save the text/html as entered. 2) How should I deal with the input and splitting of longer stories: should the user submit the html/text file and then I will have CF split the file into different database entries using some algorithm for a word count and then split at the nearest sentence or paragraph break or ?? How long is longer?. If you are using SQL Server 7.0, a single text field can contain 2 gig (a varchar can contain 8K). If you use a text field, then I wouldn't bother splitting the content. You might want to have a separate field in the table o contain a short abstract or the first paragraph/stanza. This way you can display a page with a preview of several essays/poems with little overhead. The user clicks on a "more..." button to display/download the entire content of desired articles. I have used this approach on several publication sites which display news and magazine articles. Works great! 3) Could someone explain how I might create tables to handle the split text? Should I just have a single table with title, partnum, text and then when displaying check if there is more than one partnum, or should I have a couple of tables? I don't think you need to bother to split the content. I'm starting to wonder if I should do this with a db-driven site at all :) But I've already been tied to doing a CF site with Fusebox, though the methodology is largely irrelevant. I strongly recommend the database-driven dynamic content approach. It is lot easier to maintain/search/manipulate than thousands of separate html files. HTH Dick c -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 for message encryption and authentication: USE PGP! Comment: PGP KeyID: 0x51046CFD iQA/AwUBOcPTLdaLYehRBGz9EQLN7ACfdD+BAqox51FmSnOgH4viyOCErlEAn3xH HC6gEKOqkWC7Sd0sIzORljjn =kDLa -END PGP SIGNATURE- -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_tal k or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the tips. I'm still leaning towards some way of splitting the content because I want to increase readability on the site for longer pieces by breaking the stories up in to "pages", ala Salon magazine or the like. Primarily because the site is designed for online reading... I will also provide a single page download for printing/reading offline/reading that combines the pages, but for reading online I would LIKE to try to find some middle ground between providing just an intro and the whole text. Of course, maybe I shouldn't be bothering with that approach, but as an online reader I know *I* appreciate stories that are "chunked" c -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 for message encryption and authentication: USE PGP! Comment: PGP KeyID: 0x51046CFD iQA/AwUBOcPfataLYehRBGz9EQL43gCfVj0Rrm8ARFlLRe3tkAVOdbpLLQcAn1nX ghNkiMbjHE6IoWpHBa6pdQ2W =qiS+ -END PGP SIGNATURE- -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
Ah, I see the appeal of that approach. Off the top of my head the way I would destgn the db is with 2 tables Parent Create Table Article ArticleID (PK) Title DateCreated Author . . . Abstract(text) Child Create Table ArticlePage ArticlePageID (PK) ArtickeID (FK references Article) PageNumber PageContent (text) Or, you could denormalize, and include the first page content in the Article record. Each page probably would be stored as a separate html page entity. But, if you can standardize the content format (maybe several formats) you may be able to store the content without he html. Then I would store the entire content in a single record. Then you could dynamically generate page chunks (supply the html) based on the configuration of the user's browser or by user-specified options. Searching would be much easier. BTW, the salon site appears to have simple formatting requirements. Simple enough that the content need not include any html. The Salon site could sure improve performance and reduce bandwith by using frames popups... a natural for this type of site. HTH Dick At 1:00 PM -0800 9/16/00, Chris Lott wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the tips. I'm still leaning towards some way of splitting the content because I want to increase readability on the site for longer pieces by breaking the stories up in to "pages", ala Salon magazine or the like. Primarily because the site is designed for online reading... I will also provide a single page download for printing/reading offline/reading that combines the pages, but for reading online I would LIKE to try to find some middle ground between providing just an intro and the whole text. Of course, maybe I shouldn't be bothering with that approach, but as an online reader I know *I* appreciate stories that are "chunked" c -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 for message encryption and authentication: USE PGP! Comment: PGP KeyID: 0x51046CFD iQA/AwUBOcPfataLYehRBGz9EQL43gCfVj0Rrm8ARFlLRe3tkAVOdbpLLQcAn1nX ghNkiMbjHE6IoWpHBa6pdQ2W =qiS+ -END PGP SIGNATURE- -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_tal k or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
Steve Katz, You might want to check out www.fanfiction.net for pointers. Archiving/Publishing of stories from lesser known authors is exactly what we do there. The stories are uploaded by the user and the content, no matter how large, is stored into MS SQL 2000b2 database. You can save and serve the stories out of physical files but I have found out that it is much more efficient to serve them straight from the db. Reading straight from a file and pushing that file to the web is general faster than a db solution on a small scale. However, once you have tons of traffic and thus tons of file i/o calls, the cpu spikes like crazy and everything slows down. The database, although slower under low load, is much more optimized for heavy constant reads and not to mention a internal caching mechanism. Xing www.fanfiction.net - Original Message - From: Steven Katz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 14, 2000 4:00 PM Subject: Upload and retrieval of stories? Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this material in a database, anyway? I'd be very interested to hear your suggestions. Thanks, Steven -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
If this logic is valid, wouldn't the same be true for serving images, pdf files, sound files, etc? From an application design standpoint, it is a lot cleaner to store everything in the db because: you get all the good things discipline of a db you avoid all the problems screwing around with the OS's file system So, in an ideal world, all content would be in the database. For example, I have heard thgat storing images (or any blobs) in a db will bring it to its knees. I have experimented a little with smaller images and not experienced any problems other than CF 4.0's inability to manipulate binary data. I use ASP to binary read an image, and store it in the db (never storing/renaming/deleting anything in the file system). Then a small ASP program is used to retrieve serve the images when requested in an img tag. Are you saying that if you take the broader perspective, that using a db instead of files is the most efficient way to serve content, any content? Stands to reason that saving/retrieving a few sectors in a db is a lot more efficient than going through all the overhead of allocating/opening a file, etc, then saving/retrieving a few sectors in the file Hmmm... this is very important. Got any performance stats? I'll looked at the fanfiction site... interesting Dick At 2:17 AM + 9/21/09, Xing Li wrote: Steve Katz, You might want to check out www.fanfiction.net for pointers. Archiving/Publishing of stories from lesser known authors is exactly what we do there. The stories are uploaded by the user and the content, no matter how large, is stored into MS SQL 2000b2 database. You can save and serve the stories out of physical files but I have found out that it is much more efficient to serve them straight from the db. Reading straight from a file and pushing that file to the web is general faster than a db solution on a small scale. However, once you have tons of traffic and thus tons of file i/o calls, the cpu spikes like crazy and everything slows down. The database, although slower under low load, is much more optimized for heavy constant reads and not to mention a internal caching mechanism. Xing www.fanfiction.net - Original Message - From: Steven Katz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 14, 2000 4:00 PM Subject: Upload and retrieval of stories? Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this material in a database, anyway? I'd be very interested to hear your suggestions. Thanks, Steven -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_tal k or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: Upload and retrieval of stories?
Thanks for all of the help I've received. It sounds like storing everything in the database might be the best option here. The database I will most likely use is MySQL. If I choose not to build a web-based administrative interface at this stage, what are my other options for uploading the data? Are there any good visual administrative tools? Also, if the entire story is contained within a single field of a record, how can I break it up into multiple pages, such as after a certain number of words? Steven -Original Message- From: Steve Bernard [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 14, 2000 5:06 PM To: [EMAIL PROTECTED] Subject: RE: Upload and retrieval of stories? There are a multitude of ways to do this sort of thing. I'll list a couple to get you thinking and then, if you have further questions, elaborate, as I'm sure others will as well. 1) Use form fields. The author would have to enter his story via the form, manually. 2) Use form fields. The author could enter descriptors such as title, keywords, etc. But have the body of the story uploaded via a "file" form field. Unless you have, or will build, conversion capabilities I would have the bodies uploaded as ASCII text files. For some document file types conversion is trivial while others are more difficult. 3) Upload all information as an XML document. This can be facilitated using WDDX. You could use either of the above methods with this or just send a single document. In example #1 you would convert to WDDX either at the client, via JavaScript/WDDX functions, or at the server. Example #2 would work in much the same way except you would probably want to do the conversion to ASCII text, if necessary, before encapsulating everything in XML/WDDX. If everything is sent as a single WDDX document, via a file upload (HTTP or FTP), you can either store it in the database or as a file. I haven't tried this, pipe in anybody, but, depending on your database, you may be able to query the XML data. I don't mean just pull the record, I mean use SQL queries that actually search on the XML entities within the record. I know that Oracle and MS SQL Server can do this to some degree but, I'm not sure that it will work with WDDX. Using a database is going to be extremely more effective and efficient than a file based system. Querying a file structure is an I/O intensive operation. Databases are meant for this sort of thing, so I'd use one. Once you've made your template you can easily query the database for stories and dynamically insert the content into the template for display at the client. I hope this gives you some ideas. I'm sure there are many other ways of doing this but, these came to mind first. There are a lot of great people on this list so you'll be good to go. Steve -Original Message- From: Steven Katz [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 14, 2000 7:00 PM To: [EMAIL PROTECTED] Subject: Upload and retrieval of stories? Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this material in a database, anyway? I'd be very interested to hear your suggestions. Thanks, Steven -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
Are you saying that if you take the broader perspective, that using a db instead of files is the most efficient way to serve content, any content? I don't believe db based solution is the way to go to server every type of content. In my case, this is true. The site pushes out text content in the averge range of 30KB per pop. Before, I used CF to read in files to a variable and the outputting that to the browser so basically I had CF as the bridge between the browser and file. So instead of having CF accessing the file system i/o directly I have asked CF to access the db instead. I do not have any performance numbers for you but the improvement is significant but this will only help you if you plan to do tons and tons of file reads. So basically the I have changes the previous path of : Browser Web Server ColdFusion File System to Browser Web Server ColdFusion Database If you are serving images then the fastest way to do it is stil lthe old fashioned way of : Browser Web Server File System All the new webservers are have their own caching mechanism you don't have the overhead of coldfusion,asp, or anyother tool pushing the content fromt he database to the webserver. In my experience, and since I have to do everything through ColdFusion, ColdFusion SQL is more efficient than ColdFusion File System in the long haul. However If you can skip coldfusion, skip it. No matter how fast your machine is, having the webserver caching large files is gotta to be faster than cf or sql caching/pushing out large files. Xing If this logic is valid, wouldn't the same be true for serving images, pdf files, sound files, etc? From an application design standpoint, it is a lot cleaner to store everything in the db because: you get all the good things discipline of a db you avoid all the problems screwing around with the OS's file system So, in an ideal world, all content would be in the database. For example, I have heard thgat storing images (or any blobs) in a db will bring it to its knees. I have experimented a little with smaller images and not experienced any problems other than CF 4.0's inability to manipulate binary data. I use ASP to binary read an image, and store it in the db (never storing/renaming/deleting anything in the file system). Then a small ASP program is used to retrieve serve the images when requested in an img tag. Are you saying that if you take the broader perspective, that using a db instead of files is the most efficient way to serve content, any content? Stands to reason that saving/retrieving a few sectors in a db is a lot more efficient than going through all the overhead of allocating/opening a file, etc, then saving/retrieving a few sectors in the file Hmmm... this is very important. Got any performance stats? I'll looked at the fanfiction site... interesting Dick At 2:17 AM + 9/21/09, Xing Li wrote: Steve Katz, You might want to check out www.fanfiction.net for pointers. Archiving/Publishing of stories from lesser known authors is exactly what we do there. The stories are uploaded by the user and the content, no matter how large, is stored into MS SQL 2000b2 database. You can save and serve the stories out of physical files but I have found out that it is much more efficient to serve them straight from the db. Reading straight from a file and pushing that file to the web is general faster than a db solution on a small scale. However, once you have tons of traffic and thus tons of file i/o calls, the cpu spikes like crazy and everything slows down. The database, although slower under low load, is much more optimized for heavy constant reads and not to mention a internal caching mechanism. Xing www.fanfiction.net - Original Message - From: Steven Katz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 14, 2000 4:00 PM Subject: Upload and retrieval of stories? Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this material in a database, anyway? I'd be very interested to hear your suggestions. Thanks
Re: Upload and retrieval of stories?
If you want to break up the stories into multiple pages I would suggest breaking them up at the database level and don't store everything in one field. You currently have one table which holds all the contents of the stories uploaded. If you want to have a paging scheme its probably better to go with a two table schem. Stories Table: StoryID, TimeOfUpload, etc. StoriesTextTable: StoryID, StoryTextID, Chapter, ChapterContent. This way you have unlimited number of chapters per story and generally will save you a lot of headache down the road. You can probably do it with one db but better make it scale now than later. Also, you might be interested in AppletFile by www.infomentum.com or just go to www.appletfile.com. It's a great little java applet which can upload files and even give you a progress bar of the current upload status. Just download the demo and if you don't mind the "Trial Softmare" message, you can just use it for your backend admin needs. Xing www.fanfiction.net Thanks for all of the help I've received. It sounds like storing everything in the database might be the best option here. The database I will most likely use is MySQL. If I choose not to build a web-based administrative interface at this stage, what are my other options for uploading the data? Are there any good visual administrative tools? Also, if the entire story is contained within a single field of a record, how can I break it up into multiple pages, such as after a certain number of words? Steven -Original Message- From: Steve Bernard [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 14, 2000 5:06 PM To: [EMAIL PROTECTED] Subject: RE: Upload and retrieval of stories? There are a multitude of ways to do this sort of thing. I'll list a couple to get you thinking and then, if you have further questions, elaborate, as I'm sure others will as well. 1) Use form fields. The author would have to enter his story via the form, manually. 2) Use form fields. The author could enter descriptors such as title, keywords, etc. But have the body of the story uploaded via a "file" form field. Unless you have, or will build, conversion capabilities I would have the bodies uploaded as ASCII text files. For some document file types conversion is trivial while others are more difficult. 3) Upload all information as an XML document. This can be facilitated using WDDX. You could use either of the above methods with this or just send a single document. In example #1 you would convert to WDDX either at the client, via JavaScript/WDDX functions, or at the server. Example #2 would work in much the same way except you would probably want to do the conversion to ASCII text, if necessary, before encapsulating everything in XML/WDDX. If everything is sent as a single WDDX document, via a file upload (HTTP or FTP), you can either store it in the database or as a file. I haven't tried this, pipe in anybody, but, depending on your database, you may be able to query the XML data. I don't mean just pull the record, I mean use SQL queries that actually search on the XML entities within the record. I know that Oracle and MS SQL Server can do this to some degree but, I'm not sure that it will work with WDDX. Using a database is going to be extremely more effective and efficient than a file based system. Querying a file structure is an I/O intensive operation. Databases are meant for this sort of thing, so I'd use one. Once you've made your template you can easily query the database for stories and dynamically insert the content into the template for display at the client. I hope this gives you some ideas. I'm sure there are many other ways of doing this but, these came to mind first. There are a lot of great people on this list so you'll be good to go. Steve -Original Message- From: Steven Katz [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 14, 2000 7:00 PM To: [EMAIL PROTECTED] Subject: Upload and retrieval of stories? Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this ma
RE: Upload and retrieval of stories?
If you are using an RDBMS with good XML support you can store the full story in one field and query its internal XML structure natively within the db. If the stories are huge you may run into performance problems. If this is the case, a combination of multiple chapter records in an XML format would be best. And your tech buddies will think it's tre' cool ;) Steve -Original Message- From: Xing Li [mailto:[EMAIL PROTECTED]] Sent: Friday, September 15, 2000 1:04 PM To: [EMAIL PROTECTED] Subject: Re: Upload and retrieval of stories? If you want to break up the stories into multiple pages I would suggest breaking them up at the database level and don't store everything in one field. You currently have one table which holds all the contents of the stories uploaded. If you want to have a paging scheme its probably better to go with a two table schem. Stories Table: StoryID, TimeOfUpload, etc. StoriesTextTable: StoryID, StoryTextID, Chapter, ChapterContent. This way you have unlimited number of chapters per story and generally will save you a lot of headache down the road. You can probably do it with one db but better make it scale now than later. Also, you might be interested in AppletFile by www.infomentum.com or just go to www.appletfile.com. It's a great little java applet which can upload files and even give you a progress bar of the current upload status. Just download the demo and if you don't mind the "Trial Softmare" message, you can just use it for your backend admin needs. Xing www.fanfiction.net -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
I'm thinking of going this route for another application, with one exception, the DB read/write would be once. That is, I'm thinking of storing HTML content in a DB, and, when the HTML is completed for a given CF template, place each block of HTML content in to its specific location on the CF template (which could already contain some CF tags) and then write the file to disk. This would be for simple websites, and would allow users to edit HTML, but not CF. (CF tags would be screened out of user input.) I realize there are a few content managers out there. And perhaps some tags that do the more limited task I'm think of. Suggestions? best, paul At 10:03 AM 9/15/00 -0700, you wrote: If you want to break up the stories into multiple pages I would suggest breaking them up at the database level and don't store everything in one field. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
ing images, pdf files, sound files, etc? From an application design standpoint, it is a lot cleaner to store everything in the db because: you get all the good things discipline of a db you avoid all the problems screwing around with the OS's file system So, in an ideal world, all content would be in the database. For example, I have heard thgat storing images (or any blobs) in a db will bring it to its knees. I have experimented a little with smaller images and not experienced any problems other than CF 4.0's inability to manipulate binary data. I use ASP to binary read an image, and store it in the db (never storing/renaming/deleting anything in the file system). Then a small ASP program is used to retrieve serve the images when requested in an img tag. Are you saying that if you take the broader perspective, that using a db instead of files is the most efficient way to serve content, any content? Stands to reason that saving/retrieving a few sectors in a db is a lot more efficient than going through all the overhead of allocating/opening a file, etc, then saving/retrieving a few sectors in the file Hmmm... this is very important. Got any performance stats? I'll looked at the fanfiction site... interesting Dick At 2:17 AM + 9/21/09, Xing Li wrote: Steve Katz, You might want to check out www.fanfiction.net for pointers. Archiving/Publishing of stories from lesser known authors is exactly what we do there. The stories are uploaded by the user and the content, no matter how large, is stored into MS SQL 2000b2 database. You can save and serve the stories out of physical files but I have found out that it is much more efficient to serve them straight from the db. Reading straight from a file and pushing that file to the web is general faster than a db solution on a small scale. However, once you have tons of traffic and thus tons of file i/o calls, the cpu spikes like crazy and everything slows down. The database, although slower under low load, is much more optimized for heavy constant reads and not to mention a internal caching mechanism. Xing www.fanfiction.net - Original Message - From: Steven Katz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 14, 2000 4:00 PM Subject: Upload and retrieval of stories? Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this material in a database, anyway? I'd be very interested to hear your suggestions. Thanks, Steven -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. - - Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_tal k or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -
Re: Upload and retrieval of stories?
Err this database already exists...I call it a file system. What would you dynamically change in an image? Changing the size of an image is already possible via the img tag. Changing resolution on the fly would require processing power that is way beyond capabilities today, not to mention the browsers dont support over 72x72... jon - Original Message - From: "Dick Applebaum" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 15, 2000 4:40 PM Subject: Re: Upload and retrieval of stories? Xing Good points! But, then, why doesn't it, also, make sense to use static html pages (processed and cached by the web server) and avoid CF SQL altogether. A little bit of devil's advocate role playing here. I understand the advantages/costs/tradeoffs of DDC (Database-generqated Dynamic Content) for presentation of html pages. I just think that the same may apply to non-text Content. The difference I see is that: text content is likely to change (correct spelling, format, format option for printing, etc) most non-text content probably won't change (other than be replaced by different static content) This may change in the future as we may want to programatically manipulate non=text content before presentation. An example might be to reduce the size/resolution (or other manipulation) of an image or sound file before presentation... kind of a dynamic thumbnail. There are programs such as ImageMagik which can do this for images, probably something exists for If there is a need to maintain a large repository of digital (non-text) content then a database appears to offer some significant advantages for: accessing, cataloging, security, referential integrity, backup... Maybe the advantages of database will change the way non-text content is stored and served. How about a "specialty server" optimized for this purpose. This server would efficiently access and cache large binary files. A request for content would go directly to the "specialty Server", bypassing both Application Server and Web Servers. The "Specialty Server" would receive the request, retrieve the requested content, attach the appropriate headers/mime-type and serve the content, directly. As the web evolves, we may need to change the way we think about non-text content... ... what, with applets, embeds, images,etc - what percentage of the typical page (at the browser client) is actually text? Apple's new OSX uses Quartz for presentation services... this mean that everything you see on the screen is in PDF format. (See below). Does this mean that we could serve PDF pages directly to a Mac Client and eliminate all plug-ins browser overhead, extra OS Presentation overhead... probably! Couldn't the same approach apply to images, audio, video... probably! Just some questions/thoughts. Sorry for rambling. * Quartz. Based on the Internet-standard PDF (Portable Document Format), Quartz is a power-ful new 2D graphics system that delivers on-the-fly rendering, anti-aliasing, and compositing of PostScript-strength graphics with pristine quality. Thanks to Quartz, graphic elements that were sharp before are now dramatically sharper-even when their size is greatly increased. Every-thing graphics pros create in 2D will have stunning impact . Quartz features built-in support for PDF, enabling users to embed and manipulate PDF data with any optimized Mac OS X application. Users can also "print to PDF," giving them the ability to output any document as a PDF file. So you can easily create Quartz-enhanced, graphics-rich documents that can be shared with anyone. Since this capability is available to all Mac OS X applications, Macintosh developers now have a whole new palette of creative tools at their disposal. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
Jon First, changing the size of an image with the image tag only changes what is displayed, not what is accessed by the web server, served, downloaded and cached by the browser. There is at least one server-side program that can do quite a bit to dynamically change an image at the server: real resizing, cropping, overwriting with text (maybe in the client's language) Have a look at; http://www.wizards.dupont.com/cristy/ImageMagick.html and a rudimentary interactive interface at: http://www.imagemagick.org/MagickStudio/scripts/MagickStudio.cgi/ Now, say that you have a database of very high-resolution images that you sell (the user can download). The high resolution is necessary for off-line rendering/printing, say, millions of colors at 1000x1000 pixels or greater.. A user wants to preview an image at one or more sizes at 72x72 or 300x300 (for sample printing). You could download the large file and display at 72x72... a real waste of bandwidth. The user would have to buy the image, sight quality, unseen, because once it's downloaded... You could maintain several size/resolution files to try and anticipate what the user will want... but that is a waste of file/directory slots, probably wouldn't give the user what he wants, and is ugly to program/keep track of Or, you could let the user any select the size/resolution/cropping, etc. that he wants. then server-side transform the image and download. The user could experiment at several lower resolutions before starting a large download that wouldn't give him what he wants Kodak offers some of these capabilities with its picture disk offering. A file system is not very good at this task: A limited number of directory entry, then you the programmer must decide to spill to another directory, create it, etc... no protection from deleting or changing the image while enforcing that the corresponding database reference to the file is synchronized Inability to treat the "database" as an entity, say for backup more overhead (time and storage) to manipulate individual images You, the developer, must write garbage-collection programs to resolve orphans and other inconsistencies between what is in the database and what's in the file system You don't get all the good things a database offers. Your point that "this database already exists...I call it a file system" could apply equally to any free-form content such as the "article" content used to serve dynamic pages. I don't want to start a flame, but, you could do without a database altogether and just use the file system. I have written shopping carts, etc using flat-file text files to simulate a database (separate tables, indexes, relationships). It's messy, but it works. My point was this. I am looking for a better way to manage a large number of binary files: a file system alone is not very good a db front-end to a file system is better. A db-only solution would be better yet, if it is practical... ... someday, it will be! We have to start somewhere! There probably is enough justification to develop a "special purpose" database server to begin to address applications such as: medical images such as x-rays or MRI-scans legal records voice mail entertainment such as audio/video business - architect plans/drawings real estate walk-thrus law enforcement - voice/finger prints Dick At 8:37 PM -0400 9/15/00, Jon Hall wrote: Err this database already exists...I call it a file system. What would you dynamically change in an image? Changing the size of an image is already possible via the img tag. Changing resolution on the fly would require processing power that is way beyond capabilities today, not to mention the browsers dont support over 72x72... jon - Original Message - -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: Upload and retrieval of stories?
At 8:37 PM -0400 9/15/00, Jon Hall wrote: Err this database already exists...I call it a file system. What would you dynamically change in an image? Changing the size of an image is already possible via the img tag. Changing resolution on the fly would require processing power that is way beyond capabilities today, not to mention the browsers dont support over 72x72... We integrate the TrueSpectra Accelerate dynamic image server (http://truespectra.com) with ColdFusion for applications like this: http://lookclose.com/slideshow/Ron/Kaori and the Java applet version: http://lookclose.com/zoomlet/Ron/Kaori Here's an example of an image URL (watch the line wrap): http://images.lookclose.com:/Demo/CrownGraphic/ACloseView.JPG?wid=200cv t=jpeg Change the wid value to anything between 1 and 1000, and you'll see how quick the image server spits out the right size. It's not cheap, at $5K per CPU... but it sure performs and caches well. Ron Allen Hornbaker President/CTO Humankind Systems, Inc. http://humankindsystems.com mailto:[EMAIL PROTECTED] -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
But, then, why doesn't it, also, make sense to use static html pages (processed and cached by the web server) and avoid CF SQL altogether. I agree. The best, fastest, and most scaleable way to push pages is to push pre-generated "static" pages as much as possible. I personally would love to cache everything in the database and have a dedicated server which pumps out new versions every 30 minutes or so. But a lot of the sites now a days are so dynamic it's not possible to skip the cf or sql all together. What I like to do is cache the slowest and not frequently modified part of a site to the database and update the content every 30 minutes. This may change in the future as we may want to programatically manipulate non=text content before presentation. If there is a need to maintain a large repository of digital (non-text) content then a database appears to offer some significant advantages for: accessing, cataloging, security, referential integrity, backup... As the web evolves, we may need to change the way we think about non-text content... In a couple of years I bet almost everything and anything will be dynamic. With XML climbing the ladder as of late I could see a reduction of binary files. I could see the entire web site delivered as XML text in compressed form and everything including the images will be described in a format similar to SVG. Even now, with SVG, we can use any application server to pump out vector graphics with the vistor's name customized below the site logo. On the subject of text, I believe all major browsers has an internal gzip decompressor with can deflate the compressed html stream from a web server. Which webservers compresses the outgoing streams? Is there an option in IIS that we can set or is this automatic? I'm just curious and would love to save some bandwith. ... what, with applets, embeds, images,etc - what percentage of the typical page (at the browser client) is actually text? Apple's new OSX uses Quartz for presentation services... this mean that everything you see on the screen is in PDF format. (See below). Does this mean that we could serve PDF pages directly to a Mac Client and eliminate all plug-ins browser overhead, extra OS Presentation overhead... probably! Couldn't the same approach apply to images, audio, video... probably! Didn't Apple go with the PDF approach because the PostScript licensing was too mcuh? There was this big discussion at the mac site a while back regarding this. Supposedly PDF can't handle remote imaging but PostScript can. It's been a while so I can be totally wrong in this. I would have bought OS X beta if it had support for Airport. But yeah, that would be a dream of every web developer: having total and constant control of the client/server connection/interaction. Now you have got me dreaming. =) In a few years. Xing -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: Upload and retrieval of stories?
Ron So, something does exist. Couldn't tell from the truespectra.com site much about the product. Got any general info you would share? Hardware req'ts? Software req'ts? Performance options available? (load balancing, clustering, etc.) To store images do they use: Native OS File system and/or database Proprietary file system and/or database Where are the images stored Where is the Descriptive info (Title, Caption, attributes, etc.) Store TIA Dick At 10:15 PM -0500 9/15/00, [EMAIL PROTECTED] wrote: At 8:37 PM -0400 9/15/00, Jon Hall wrote: Err this database already exists...I call it a file system. What would you dynamically change in an image? Changing the size of an image is already possible via the img tag. Changing resolution on the fly would require processing power that is way beyond capabilities today, not to mention the browsers dont support over 72x72... We integrate the TrueSpectra Accelerate dynamic image server (http://truespectra.com) with ColdFusion for applications like this: http://lookclose.com/slideshow/Ron/Kaori and the Java applet version: http://lookclose.com/zoomlet/Ron/Kaori Here's an example of an image URL (watch the line wrap): http://images.lookclose.com:/Demo/CrownGraphic/ACloseView.JPG?wid=200cv t=jpeg Change the wid value to anything between 1 and 1000, and you'll see how quick the image server spits out the right size. It's not cheap, at $5K per CPU... but it sure performs and caches well. Ron Allen Hornbaker President/CTO Humankind Systems, Inc. http://humankindsystems.com mailto:[EMAIL PROTECTED] -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Upload and retrieval of stories?
Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this material in a database, anyway? I'd be very interested to hear your suggestions. Thanks, Steven -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Upload and retrieval of stories?
I'm not sure if there is one in CF but if not, there is a great utility for doing this in Perl. You could easily use with CF. I've used it and it works great looks a little rough but it can easily be massaged. Download it here: http://amphibian.gagames.com/newspro/ -Mark :o) - Original Message - From: Steven Katz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 14, 2000 4:00 PM Subject: Upload and retrieval of stories? Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this material in a database, anyway? I'd be very interested to hear your suggestions. Thanks, Steven -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: Upload and retrieval of stories?
There are a multitude of ways to do this sort of thing. I'll list a couple to get you thinking and then, if you have further questions, elaborate, as I'm sure others will as well. 1) Use form fields. The author would have to enter his story via the form, manually. 2) Use form fields. The author could enter descriptors such as title, keywords, etc. But have the body of the story uploaded via a "file" form field. Unless you have, or will build, conversion capabilities I would have the bodies uploaded as ASCII text files. For some document file types conversion is trivial while others are more difficult. 3) Upload all information as an XML document. This can be facilitated using WDDX. You could use either of the above methods with this or just send a single document. In example #1 you would convert to WDDX either at the client, via JavaScript/WDDX functions, or at the server. Example #2 would work in much the same way except you would probably want to do the conversion to ASCII text, if necessary, before encapsulating everything in XML/WDDX. If everything is sent as a single WDDX document, via a file upload (HTTP or FTP), you can either store it in the database or as a file. I haven't tried this, pipe in anybody, but, depending on your database, you may be able to query the XML data. I don't mean just pull the record, I mean use SQL queries that actually search on the XML entities within the record. I know that Oracle and MS SQL Server can do this to some degree but, I'm not sure that it will work with WDDX. Using a database is going to be extremely more effective and efficient than a file based system. Querying a file structure is an I/O intensive operation. Databases are meant for this sort of thing, so I'd use one. Once you've made your template you can easily query the database for stories and dynamically insert the content into the template for display at the client. I hope this gives you some ideas. I'm sure there are many other ways of doing this but, these came to mind first. There are a lot of great people on this list so you'll be good to go. Steve -Original Message- From: Steven Katz [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 14, 2000 7:00 PM To: [EMAIL PROTECTED] Subject: Upload and retrieval of stories? Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this material in a database, anyway? I'd be very interested to hear your suggestions. Thanks, Steven -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: Upload and retrieval of stories?
In terms of the form field, use a text area with virtual wrap for pasting large amounts of text. I have programmed several of these 'publishing systems' successfully using forms, CF and a database. Sincerely, Shane Witbeck Webmaster mailto:[EMAIL PROTECTED] www.digitalsanctum.com -Original Message- From: Steven Katz [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 14, 2000 7:00 PM To: [EMAIL PROTECTED] Subject: Upload and retrieval of stories? Hi all, I'm developing a site that will feature short- to medium-length stories from lesser-known authors. I have designed a page that will serve as a template, into which I will insert the material contributed from the authors. I would rather that this process of inserting content not be a manual one. In fact, I would like the programmatic solution to include a web-based administrative interface. Normally, this might consist of some forms and CF or PHP, allowing the user to upload content to a database, where the material could then also be made available to the templates for the dynamic creation of pages. However, form fields seem to have a rather small character limit, preventing one from simply pasting an entire story into them. This isn't really what I want to do anyway. Has anyone devised a good process for accomplishing something similar? Perhaps there's no reason to store this material in a database, anyway? I'd be very interested to hear your suggestions. Thanks, Steven -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
