Menu
▾
▴
modus-devs — List for Modus Developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(72) |
Oct
(15) |
Nov
(68) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian G. <br...@vf...> - 2002-09-18 18:58:52
|
Client side validation is an important piece of the user experience pie. It is not, however, to ensure data integrity. A proper application includes both pieces. Check out qForms at http://www.pengoworks.com. Brian Brad Pauly wrote: > > How could I forget forms. I am not a fan of client side validation. > Having a way to create form fields and define there validation rules, > yet have it all handled for me via the framework, that would be nice. > Oh, and make it flexible enough so I have full control of the layout. > > Brad |
|
From: Brad P. <br...@ro...> - 2002-09-18 18:35:29
|
How could I forget forms. I am not a fan of client side validation. Having a way to create form fields and define there validation rules, yet have it all handled for me via the framework, that would be nice. Oh, and make it flexible enough so I have full control of the layout. Brad |
|
From: Brad P. <br...@ro...> - 2002-09-18 18:34:22
|
I have been thinking about the framework aspect of Modus and would like to discuss what a "good" framework would provide. I've read most of the threads on BACFUG on this topic, but feel like there hasn't been a good summary of "this is what a good framework offers a developer", or even a thread that leads you to that point. So here is what I think would be beneficial. To start I have never used fusebox. I grabbed the example app once and got it running, but that is all. At my previous job we used a fusebox-like technique in that we ran every request through one template and it handled including the proper file. I didn't really like the way we were doing it. It seemed like a lot of work and overly complex to use a case statement. I do however think that it is nice to have something take care of mapping requests to the right place and avoiding ugly errors. So if a user mangles the URL, the application handles it gracefully. Error handling is something else I would want. Some central error handling object of sorts. I might still want to do my own try/catch, but I want to hand that error off to something else and let it deal with what to do with it. Maybe nothing happens for a non-critical error, maybe it gets logged, and maybe it is useful information for the user and gets passed to something that knows how to display it. Is it worth defining error codes? I've been doing php development lately and since there is no <cfquery>, I usually write a query class. So CF has this handled, but could there be more? Perhaps error handling could be done in a query component. This may not have much value. Nathan mentioned security and I think this would definitely be good. There are lots of places that security could touch. Client authentication comes to mind as well as user permissions. I don't think these would be handled by the same thing. Could a framework handle permissions without tying a developer to a certain way of handling users? A request handler might take care of some security, like examining a URL for bad things. This could be handled by the web server, but I think it would be nice to have it taken care of "out of the box". Of course persistence, which is already addressed for content objects. If this is to be legit in the eyes of "serious" CFers, should there be something more scalable? Concerning session persistence, I am a fan of Brian's rsession. Something like that with a file system storage option. I actually started doing that a few months ago when first trying out CFMX. Unfortunately it was on my sole windows box, which was recently reclaimed to play with LTSP =) It's always good to rewrite things a few times anyway. Isn't that what good writers do ;) Ok, that's about all I have for now. Hopefully I managed to put my thoughts in a form that is clear. Feedback is welcomed and highly encouraged! Brad |
|
From: Brad P. <br...@ro...> - 2002-09-18 03:43:05
|
On Tuesday, September 17, 2002, at 08:43 PM, Nathan Dintenfass wrote: > > Well, I started building Modus for two reasons. Well, three actually. > > 1) I wanted to do something "real" with components -- and do it using > component metaData > > 2) I was disturbed at a recent BACFUG meeting, where someone asked > "well, if not Fusebox, then what > CF framework should I use" -- the answer was "there isn't one". I'm > not sure if Modus can ever be > the one, but the community sure could use an open, free framework that > was at least considered legit > by "serious" CF people. That would be the main reason to include > stuff like page wrappers, > security, etc. > > 3) I had a project I was going to be working on, and this was way more > fun than actually just > building it out (which I ended up doing anyway ;) Cool. I think it would be a great thing to create a CF framework. I am interested in helping if I can. So now I am wondering what the best way to approach this is. Maybe we can start a discussion about the possible steps to take to achieve this. If this is indeed the goal. Any thoughts? Brad |
|
From: Nathan D. <na...@ch...> - 2002-09-18 02:46:10
|
> > I was also talking the other day about what the scope of Modus will ultimately be. For > instance, > > what about "page wrappers" and navigation -- should Modus include mechanisms for that? > Security and > > Personalization? > > I am not sure Modus should handle these things. It seems that it is > built specifically for content management. At least at the moment. Maybe > it is worth generalizing some of the components. I was thinking mostly > of the persister. Does it make sense to have a basePersister on the same > level as the baseContentObject? > > I think a "page wrapper" could be nice. This could probably take on any > number of definitions. From serving up headers and footers to a file > naming convention or request mapper and probably into a framework. And a > framework might include some security. I suppose the sky is the limit. > Hehe, that isn't much of an answer. If it makes any difference, I plan > on giving my input at the very least, and eventually contributing some > code or maybe documentation. Well, I started building Modus for two reasons. Well, three actually. 1) I wanted to do something "real" with components -- and do it using component metaData 2) I was disturbed at a recent BACFUG meeting, where someone asked "well, if not Fusebox, then what CF framework should I use" -- the answer was "there isn't one". I'm not sure if Modus can ever be the one, but the community sure could use an open, free framework that was at least considered legit by "serious" CF people. That would be the main reason to include stuff like page wrappers, security, etc. 3) I had a project I was going to be working on, and this was way more fun than actually just building it out (which I ended up doing anyway ;) |
|
From: Brad P. <br...@ro...> - 2002-09-17 23:47:11
|
On Mon, 2002-09-16 at 20:10, Nathan Dintenfass wrote: > I have been thinking that for Modus to be considered truly functional it will need to be able to > build something like an events calendar, with different types of events. This would require > sorting, filtering, joins, and multi-value fields -- all of which are going to be necessary for > Modus to ever be ready for "prime time". > > In the shorter term, I think that any simple dynamic content site could be built in Modus. The > premise should be that it's faster to build and easier to maintain than doing it with "just plain > ColdFusion" (otherwise, why bother at all?). > > I was considering trying to get the new BACFUG site kickin' in Modus, but I will likely not have > time for that (free time to be spent actually building Modus ;) I will try to spend some time working on a simple app. It will help (force;) me to dig into the code further. I might even take a swing at some of the stuff on the bacfug site. > I was also talking the other day about what the scope of Modus will ultimately be. For instance, > what about "page wrappers" and navigation -- should Modus include mechanisms for that? Security and > Personalization? I am not sure Modus should handle these things. It seems that it is built specifically for content management. At least at the moment. Maybe it is worth generalizing some of the components. I was thinking mostly of the persister. Does it make sense to have a basePersister on the same level as the baseContentObject? I think a "page wrapper" could be nice. This could probably take on any number of definitions. From serving up headers and footers to a file naming convention or request mapper and probably into a framework. And a framework might include some security. I suppose the sky is the limit. Hehe, that isn't much of an answer. If it makes any difference, I plan on giving my input at the very least, and eventually contributing some code or maybe documentation. Brad > - n > > > > -----Original Message----- > > From: mod...@li... > > [mailto:mod...@li...]On Behalf Of Brad Pauly > > Sent: Monday, September 16, 2002 6:49 PM > > To: mod...@li... > > Subject: [Modus-devs] sample application > > > > > > I was wondering what might be a good sample application for Modus. I > > suppose modustest could be expanded. Any other thoughts? > > > > Brad > > > > > > > > ------------------------------------------------------- > > Sponsored by: AMD - Your access to the experts on Hammer Technology! > > Open Source & Linux Developers, register now for the AMD Developer > > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > > _______________________________________________ > > Modus-devs mailing list > > Mod...@li... > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > ------------------------------------------------------- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > |
|
From: Nathan D. <na...@ch...> - 2002-09-17 02:12:39
|
I have been thinking that for Modus to be considered truly functional it will need to be able to build something like an events calendar, with different types of events. This would require sorting, filtering, joins, and multi-value fields -- all of which are going to be necessary for Modus to ever be ready for "prime time". In the shorter term, I think that any simple dynamic content site could be built in Modus. The premise should be that it's faster to build and easier to maintain than doing it with "just plain ColdFusion" (otherwise, why bother at all?). I was considering trying to get the new BACFUG site kickin' in Modus, but I will likely not have time for that (free time to be spent actually building Modus ;) I was also talking the other day about what the scope of Modus will ultimately be. For instance, what about "page wrappers" and navigation -- should Modus include mechanisms for that? Security and Personalization? - n > -----Original Message----- > From: mod...@li... > [mailto:mod...@li...]On Behalf Of Brad Pauly > Sent: Monday, September 16, 2002 6:49 PM > To: mod...@li... > Subject: [Modus-devs] sample application > > > I was wondering what might be a good sample application for Modus. I > suppose modustest could be expanded. Any other thoughts? > > Brad > > > > ------------------------------------------------------- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > |
|
From: Brad P. <br...@ro...> - 2002-09-17 01:48:47
|
I was wondering what might be a good sample application for Modus. I suppose modustest could be expanded. Any other thoughts? Brad |
|
From: Brad P. <br...@ro...> - 2002-09-16 23:25:32
|
Wow. Looks excellent. IIRC PowerPC chips have a different kind of speed rating. I remember something about a 500Mhz ppc being roughly equivalent to a 1Ghz Pentium. I could easily be wrong. That along with the fact that a 1.4Mhz PIII is probably not really running at 1.4Mhz (yay marketing) makes me less confident in their results. Even so, it performs well. It would be interesting to see how CFMX did on different platforms. If you factor in how cool they look, the Xserve wins hands down =) Brad On Mon, 2002-09-16 at 17:09, Ben Archibald wrote: > Hey: > > Yeah....and what do you make of the benchmarks (by apple) seen at: > > http://www.apple.com/xserve/performance.html > > ?? Kinda makes me wanna serve off of Mac. > > - Ben Archibald > > -----Original Message----- > From: mod...@li... > [mailto:mod...@li...]On Behalf Of Brad Pauly > Sent: Monday, September 16, 2002 3:58 PM > To: mod...@li... > Subject: [Modus-devs] OSX > > > I guess it is no surprise considering it runs on Linux just fine. > Anyway, it runs on OSX as well. No problems, directly from cvs. > > Brad > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > |
|
From: Ben A. <be...@ch...> - 2002-09-16 23:04:28
|
Hey: Yeah....and what do you make of the benchmarks (by apple) seen at: http://www.apple.com/xserve/performance.html ?? Kinda makes me wanna serve off of Mac. - Ben Archibald -----Original Message----- From: mod...@li... [mailto:mod...@li...]On Behalf Of Brad Pauly Sent: Monday, September 16, 2002 3:58 PM To: mod...@li... Subject: [Modus-devs] OSX I guess it is no surprise considering it runs on Linux just fine. Anyway, it runs on OSX as well. No problems, directly from cvs. Brad ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Modus-devs mailing list Mod...@li... https://lists.sourceforge.net/lists/listinfo/modus-devs |
|
From: Brad P. <br...@ro...> - 2002-09-16 22:58:10
|
I guess it is no surprise considering it runs on Linux just fine. Anyway, it runs on OSX as well. No problems, directly from cvs. Brad |
|
From: Nathan D. <na...@ch...> - 2002-09-14 23:34:49
|
> I did run into one problem with uploading PNGs. It was a problem before > I grabbed the latest, so it is not new. I haven't looked into it, but I > get an error when I try to upload a PNG that says: > > "ERROR: The file uploaded is not a proper web image (GIF, JPEG, or PNG)" > This is probably my bad. I haven't worked much with PNG, and I just grabbed a random PNG off the web and tried its mime type via IE5 and used that. It just needs to add it to the list in that rule. - Nathan |
|
From: Brad P. <br...@ro...> - 2002-09-14 22:30:11
|
Worked fine without making any changes. Just grabbed the latest and was good to go. I am _really_ hoping to get cfmx running on my powerbook today and will test it more after that happens. I did run into one problem with uploading PNGs. It was a problem before I grabbed the latest, so it is not new. I haven't looked into it, but I get an error when I try to upload a PNG that says: "ERROR: The file uploaded is not a proper web image (GIF, JPEG, or PNG)" That's all I have for now...back to the laptop =) Brad On Fri, 2002-09-13 at 19:25, Nathan Dintenfass wrote: > I have checked in the new simpleFileSystemPersister.cfc I didn't have a > chance to test it extensively, but I could add/edit on the modustest app. > > Comments are welcomed. > > - n > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > |
|
From: Nathan D. <na...@ch...> - 2002-09-14 01:23:40
|
I have checked in the new simpleFileSystemPersister.cfc I didn't have a chance to test it extensively, but I could add/edit on the modustest app. Comments are welcomed. - n |
|
From: Brad P. <br...@ro...> - 2002-09-14 00:34:38
|
I see. That makes sense. On Fri, 2002-09-13 at 18:30, Nathan Dintenfass wrote: > > > What about the storage of other content, like images? > > > > Well, I think this would depend on the content object type. For instance, > my current webImage field just sticks images in the web root (I'm assuming > that will change) -- though this is actually in the baseFile field, which > will eventually have some kind of interface to set the path. So, basically, > I think each field type and/or content object type should define where it > gets stored, as that is not a core Modus function. > > Make sense? > > - n > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > |
|
From: Nathan D. <na...@ch...> - 2002-09-14 00:28:55
|
> What about the storage of other content, like images? > Well, I think this would depend on the content object type. For instance, my current webImage field just sticks images in the web root (I'm assuming that will change) -- though this is actually in the baseFile field, which will eventually have some kind of interface to set the path. So, basically, I think each field type and/or content object type should define where it gets stored, as that is not a core Modus function. Make sense? - n |
|
From: Brad P. <br...@ro...> - 2002-09-13 23:58:42
|
I don't think the files would get very large. The way I was playing around with it was to have 4 directories each 4 deep with 4 directories on each level. That gives (if my math is correct) 256 bottom level directories. So directoyList would be at most 256 lines (short ones). It does seem like this would be more steps than necessary. I do like your solution of appending the objectType to the file name. What about the storage of other content, like images? Brad On Fri, 2002-09-13 at 17:35, Nathan Dintenfass wrote: > I am trying to avoid having to read files to do a get or a getAll, as > reading large files and parsing them would be very expensive relative to > listing out directory contents. > > I'm also now thinking that if I am going to store them in one big directory > anyway, I might just store them named like: > > objectID.objectType > > I could then just use the filter attribute of CFDIRECTORY when getting all > of a certain type. > > Most contenObjects will only be a few kb stored as flat files, and I figure > nobody will use the file storage for many many thousands of objects, so it > should work. > > - n > > > -----Original Message----- > > From: mod...@li... > > [mailto:mod...@li...]On Behalf Of Brad Pauly > > Sent: Friday, September 13, 2002 3:57 PM > > To: modus devs > > Subject: RE: [Modus-devs] advice on file-based persistence > > > > > > I had another idea about storing objects. Using both the idea of keeping > > object types in separate directories and distributing the files into > > subdirectories. Then keeping a list of the directories in a file in the > > object type directory. So a path would look something like: > > > > <objectStoreRoot>/<objectType>/1/4/2/3/45740C9C-CCFF-20DE-D6C92C971A2A440B > > <objectStoreRoot>/<objectType>/1/4/4/1/45743C16-B5C3-75BC-CC9F7E3E7598099D > > > > <objectStoreRoot>/<objectType>/directoryList.txt > > > > <directoryList.txt> > > > > /1/4/2/3/ > > /1/4/4/1/ > > > > </directoryList.txt> > > > > When you did a getAll, you would have to read the file, then get a > > listing from each of the directories. I don't know if that is any better > > than reading a huge file of all the object files. It could just as > > easily be an xml file. That might be easier to handle. I haven't > > actually tried any of the new xml functions in cfmx yet. The other thing > > that might be useful is that you could change the distribution scheme > > and it would still work fine. > > > > It might be more work than it is worth. And it might be worth much, but > > I wanted to throw it out there. I may give it a test or two this > > evening. What do you guys think? > > > > Brad > > > > > > On Fri, 2002-09-13 at 08:43, Nathan Dintenfass wrote: > > > But, what happens at 10,000 files? It's one thing to be slow, > > it would be > > > another to bring a machine to its knees. I did a little searching, but > > > didn't find any hard and fast number on limits. > > > > > > Do you think it matters how big the file are? I tend to doubt > > it, but if > > > anyone has better info . . . > > > > > > - n > > > > > > > -----Original Message----- > > > > From: mod...@li... > > > > [mailto:mod...@li...]On Behalf Of Brian > > > > Ghidinelli > > > > Sent: Thursday, September 12, 2002 10:10 PM > > > > To: mod...@li... > > > > Subject: Re: [Modus-devs] advice on file-based persistence > > > > > > > > > > > > > > > > Nathan Dintenfass wrote: > > > > > Again, I don't think the file-based storage needs to be very > > > > scalable, as > > > > > anyone looking to run a scalable app will choose a > > different persistence > > > > > mechanism. The file-based persister is just for "out-of-the-box" > > > > > implementation and simple sites that don't have access to a > > database. > > > > > > > > I think for this reason alone you should go all files in one > > directory. > > > > Even if you had a "big" site running off of file system > > persistence and > > > > you had 2500 files in a directory, you would probably be just > > fine on most > > > > file systems. > > > > > > > > > > > > Brian > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > _______________________________________________ > > > > Modus-devs mailing list > > > > Mod...@li... > > > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Modus-devs mailing list > > > Mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Modus-devs mailing list > > Mod...@li... > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > |
|
From: Nathan D. <na...@ch...> - 2002-09-13 23:34:23
|
I am trying to avoid having to read files to do a get or a getAll, as reading large files and parsing them would be very expensive relative to listing out directory contents. I'm also now thinking that if I am going to store them in one big directory anyway, I might just store them named like: objectID.objectType I could then just use the filter attribute of CFDIRECTORY when getting all of a certain type. Most contenObjects will only be a few kb stored as flat files, and I figure nobody will use the file storage for many many thousands of objects, so it should work. - n > -----Original Message----- > From: mod...@li... > [mailto:mod...@li...]On Behalf Of Brad Pauly > Sent: Friday, September 13, 2002 3:57 PM > To: modus devs > Subject: RE: [Modus-devs] advice on file-based persistence > > > I had another idea about storing objects. Using both the idea of keeping > object types in separate directories and distributing the files into > subdirectories. Then keeping a list of the directories in a file in the > object type directory. So a path would look something like: > > <objectStoreRoot>/<objectType>/1/4/2/3/45740C9C-CCFF-20DE-D6C92C971A2A440B > <objectStoreRoot>/<objectType>/1/4/4/1/45743C16-B5C3-75BC-CC9F7E3E7598099D > > <objectStoreRoot>/<objectType>/directoryList.txt > > <directoryList.txt> > > /1/4/2/3/ > /1/4/4/1/ > > </directoryList.txt> > > When you did a getAll, you would have to read the file, then get a > listing from each of the directories. I don't know if that is any better > than reading a huge file of all the object files. It could just as > easily be an xml file. That might be easier to handle. I haven't > actually tried any of the new xml functions in cfmx yet. The other thing > that might be useful is that you could change the distribution scheme > and it would still work fine. > > It might be more work than it is worth. And it might be worth much, but > I wanted to throw it out there. I may give it a test or two this > evening. What do you guys think? > > Brad > > > On Fri, 2002-09-13 at 08:43, Nathan Dintenfass wrote: > > But, what happens at 10,000 files? It's one thing to be slow, > it would be > > another to bring a machine to its knees. I did a little searching, but > > didn't find any hard and fast number on limits. > > > > Do you think it matters how big the file are? I tend to doubt > it, but if > > anyone has better info . . . > > > > - n > > > > > -----Original Message----- > > > From: mod...@li... > > > [mailto:mod...@li...]On Behalf Of Brian > > > Ghidinelli > > > Sent: Thursday, September 12, 2002 10:10 PM > > > To: mod...@li... > > > Subject: Re: [Modus-devs] advice on file-based persistence > > > > > > > > > > > > Nathan Dintenfass wrote: > > > > Again, I don't think the file-based storage needs to be very > > > scalable, as > > > > anyone looking to run a scalable app will choose a > different persistence > > > > mechanism. The file-based persister is just for "out-of-the-box" > > > > implementation and simple sites that don't have access to a > database. > > > > > > I think for this reason alone you should go all files in one > directory. > > > Even if you had a "big" site running off of file system > persistence and > > > you had 2500 files in a directory, you would probably be just > fine on most > > > file systems. > > > > > > > > > Brian > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Modus-devs mailing list > > > Mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Modus-devs mailing list > > Mod...@li... > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > |
|
From: Brad P. <br...@ro...> - 2002-09-13 23:04:57
|
I had another idea about storing objects. Using both the idea of keeping object types in separate directories and distributing the files into subdirectories. Then keeping a list of the directories in a file in the object type directory. So a path would look something like: <objectStoreRoot>/<objectType>/1/4/2/3/45740C9C-CCFF-20DE-D6C92C971A2A440B <objectStoreRoot>/<objectType>/1/4/4/1/45743C16-B5C3-75BC-CC9F7E3E7598099D <objectStoreRoot>/<objectType>/directoryList.txt <directoryList.txt> /1/4/2/3/ /1/4/4/1/ </directoryList.txt> When you did a getAll, you would have to read the file, then get a listing from each of the directories. I don't know if that is any better than reading a huge file of all the object files. It could just as easily be an xml file. That might be easier to handle. I haven't actually tried any of the new xml functions in cfmx yet. The other thing that might be useful is that you could change the distribution scheme and it would still work fine. It might be more work than it is worth. And it might be worth much, but I wanted to throw it out there. I may give it a test or two this evening. What do you guys think? Brad On Fri, 2002-09-13 at 08:43, Nathan Dintenfass wrote: > But, what happens at 10,000 files? It's one thing to be slow, it would be > another to bring a machine to its knees. I did a little searching, but > didn't find any hard and fast number on limits. > > Do you think it matters how big the file are? I tend to doubt it, but if > anyone has better info . . . > > - n > > > -----Original Message----- > > From: mod...@li... > > [mailto:mod...@li...]On Behalf Of Brian > > Ghidinelli > > Sent: Thursday, September 12, 2002 10:10 PM > > To: mod...@li... > > Subject: Re: [Modus-devs] advice on file-based persistence > > > > > > > > Nathan Dintenfass wrote: > > > Again, I don't think the file-based storage needs to be very > > scalable, as > > > anyone looking to run a scalable app will choose a different persistence > > > mechanism. The file-based persister is just for "out-of-the-box" > > > implementation and simple sites that don't have access to a database. > > > > I think for this reason alone you should go all files in one directory. > > Even if you had a "big" site running off of file system persistence and > > you had 2500 files in a directory, you would probably be just fine on most > > file systems. > > > > > > Brian > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Modus-devs mailing list > > Mod...@li... > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > |
|
From: Brian G. <br...@vf...> - 2002-09-13 15:37:09
|
Size and number of files both play into it. Some file systems are optimized for lots of little files, others are optimized for a few large files, and most are good at some combination in the middle. Since you're currently dealing with NT and NTFS, I think you need to just take what you can get. This article has a lot of info on NTFS that might help: <http://www.winnetmag.com/Articles/Index.cfm?ArticleID=4875> Brian Nathan Dintenfass wrote: > > But, what happens at 10,000 files? It's one thing to be slow, it would be > another to bring a machine to its knees. I did a little searching, but > didn't find any hard and fast number on limits. > > Do you think it matters how big the file are? I tend to doubt it, but if > anyone has better info . . . |
|
From: Nathan D. <na...@ch...> - 2002-09-13 14:42:15
|
But, what happens at 10,000 files? It's one thing to be slow, it would be another to bring a machine to its knees. I did a little searching, but didn't find any hard and fast number on limits. Do you think it matters how big the file are? I tend to doubt it, but if anyone has better info . . . - n > -----Original Message----- > From: mod...@li... > [mailto:mod...@li...]On Behalf Of Brian > Ghidinelli > Sent: Thursday, September 12, 2002 10:10 PM > To: mod...@li... > Subject: Re: [Modus-devs] advice on file-based persistence > > > > Nathan Dintenfass wrote: > > Again, I don't think the file-based storage needs to be very > scalable, as > > anyone looking to run a scalable app will choose a different persistence > > mechanism. The file-based persister is just for "out-of-the-box" > > implementation and simple sites that don't have access to a database. > > I think for this reason alone you should go all files in one directory. > Even if you had a "big" site running off of file system persistence and > you had 2500 files in a directory, you would probably be just fine on most > file systems. > > > Brian > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > |
|
From: Brian G. <br...@vf...> - 2002-09-13 05:10:16
|
Nathan Dintenfass wrote: > Again, I don't think the file-based storage needs to be very scalable, as > anyone looking to run a scalable app will choose a different persistence > mechanism. The file-based persister is just for "out-of-the-box" > implementation and simple sites that don't have access to a database. I think for this reason alone you should go all files in one directory. Even if you had a "big" site running off of file system persistence and you had 2500 files in a directory, you would probably be just fine on most file systems. Brian |
|
From: Brad P. <br...@ro...> - 2002-09-13 04:53:52
|
I would have to agree that my first thought is number 2 does sound like the best solution at the moment. At the same time I feel like there might be something else that hasn't been considered yet. Unfortunately I don't know what that is. Perhaps there is a combination of sorts that might work without anything getting too big. Symbolic links popped into my head, but I have no proposed solution. My mind tends to work better in the morning after a few cups o coffee. I will try to spend some time in the morning thinking of possibilities. Brad On Thu, 2002-09-12 at 20:36, Nathan Dintenfass wrote: > OK, I obviously did not get the file persistence done last night as > promised. Life happens ;) > > I am working on it now and running into some decisions I could some feedback > on. I know very little about file system optimization. > > My original plan was to create a directory for each object type and then > store a file for each object instance named the ID of the instance in that > directory. This created the problem of not having an easy way to just say > get(object.id). So, I figured I'd make an object "index" instead that > pointed to which type the object is stored in. But, the problem there was > that you still need to have something "big" for all the objects. > > I need to decide what will be "big" where the parameters are that I need a > way to say "get all objects of a type x" and a way to say "get object with > id of x". Some options: > > 1) One large file containing the index, which you have to read and parse > somehow (CSV, WDDX, etc.). It could point to any directory structure that > works, but has the disadvantage of needing to be read a lot. Of course, it > could be cached for reading, but still needs to be written. > > 2) A single directory filled with one file per object id, which could get > hairy with LOTS of objects. We would then build a separate directory tree > based on types, where each type directory just has a bunch of empty files > with the ID's of the appropriate objects (which would then be used to loop > through and read the "real" file. This is probably the simplest method, and > the one I am currently leaning towards. > > 3) A complex, dense, directory tree based on the ID (per Brad's suggestion), > where the object instance lives at the bottom of each branch. We'd still > need an "index" of object id's based on type as in #2. This means that no > directory ever has lots of files, but there will end up being LOTS of > directories. It's also a potential nightmare of complexity if you ever want > to manage the data en masse. > > No matter what, it seems there will need to be where object instances are > actually stored and some kind of index mechanism to look up either the type > based on ID, or the ID's based on type. > > Again, I don't think the file-based storage needs to be very scalable, as > anyone looking to run a scalable app will choose a different persistence > mechanism. The file-based persister is just for "out-of-the-box" > implementation and simple sites that don't have access to a database. > > Any suggestions/thoughts/warnings? > > - Nathan > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > |
|
From: Nathan D. <na...@ch...> - 2002-09-13 04:02:39
|
OK, I obviously did not get the file persistence done last night as promised. Life happens ;) I am working on it now and running into some decisions I could some feedback on. I know very little about file system optimization. My original plan was to create a directory for each object type and then store a file for each object instance named the ID of the instance in that directory. This created the problem of not having an easy way to just say get(object.id). So, I figured I'd make an object "index" instead that pointed to which type the object is stored in. But, the problem there was that you still need to have something "big" for all the objects. I need to decide what will be "big" where the parameters are that I need a way to say "get all objects of a type x" and a way to say "get object with id of x". Some options: 1) One large file containing the index, which you have to read and parse somehow (CSV, WDDX, etc.). It could point to any directory structure that works, but has the disadvantage of needing to be read a lot. Of course, it could be cached for reading, but still needs to be written. 2) A single directory filled with one file per object id, which could get hairy with LOTS of objects. We would then build a separate directory tree based on types, where each type directory just has a bunch of empty files with the ID's of the appropriate objects (which would then be used to loop through and read the "real" file. This is probably the simplest method, and the one I am currently leaning towards. 3) A complex, dense, directory tree based on the ID (per Brad's suggestion), where the object instance lives at the bottom of each branch. We'd still need an "index" of object id's based on type as in #2. This means that no directory ever has lots of files, but there will end up being LOTS of directories. It's also a potential nightmare of complexity if you ever want to manage the data en masse. No matter what, it seems there will need to be where object instances are actually stored and some kind of index mechanism to look up either the type based on ID, or the ID's based on type. Again, I don't think the file-based storage needs to be very scalable, as anyone looking to run a scalable app will choose a different persistence mechanism. The file-based persister is just for "out-of-the-box" implementation and simple sites that don't have access to a database. Any suggestions/thoughts/warnings? - Nathan |
|
From: Nathan D. <na...@ch...> - 2002-09-12 17:36:27
|
> > Yes, makes good sense. As far as formats for the config file. Hmm. Are > there any obvious logical lines that you could draw through the config > parameters? Actually, what are the other config parameters? Hmm. At the moment I am certain of two: defaultPersister rootModusDirectory (/WEB-INF/Modus/) I could also see a list of object types to preload into the cache when Modus initializes. If Modus expands to include things like page rendering, security, etc. I could see many things related to those issues as well. You can probably see now why I haven't yet put a config file together -- the whole thing needs a little more time to "bake" before it's clear what belongs where. Along with the config, I think there would be a modusInit.cfm that could be called as a custom tag in the Application.cfm of an app using Modus -- it would make sure the rootModusDirectory was created, would initialize the cache, the formFieldFactory, and anything else that should be in the server.modus scope. |
4 messages has been excluded from this view by a project administrator.
