text:
Kenny Howell
Managing Editor
A controversial apartment complex in Providence was approved Thursday at the Planning Commission meeting.
Meridian at Providence Trail is to be located next to Maristone Senior Living on Providence Trail, which is behind Target. It is on 14.15 acres and is a mixed use of retail and residential. The developers promised over 5,000 square feet of retail plus a Police Substation on the property so officers would have an area to write reports or store equipment. That would be free for five years at no cost to the city.
The issue was voted down at the last meeting, but came back to the table because the Commissioners did not provide a legal reason that Meridian could not develop the property as they chose because it met all the subdivision regulations which are required by the City.
Commissioner Brian Abston was unhappy with many aspects of the project, and wanted the developers to provide extra money to the schools, police department, fire department and an impact fee.
After a lengthy discussion, Attorney Tom White got up to speak during citizen comments about the legality of the project.
"Despite personal feelings about it, if in fact it meets site plan approval, then legally you have to approve it," said White.
White asked that the commission refer to City Attorney Gino Marchetti for confirmation of his position.
"As attorney for our planning commission, do you concur with Mr. White's opinion," said Commissioner Phil Smartt.
"Mr. White has accurately stated the law as it currently exists," Marchetti replied.
Chairman Luke Winchester elaborated on the position. Many people were confused why the item came back to the agenda when it was voted down the month before.
Winchester went on to say that even though they are to represent the community, they have to uphold the laws that the city sets forth in the subdivision regulations.
"We could be very much in your favor, in your corner as well," said Winchester.
When it came to a vote, Abston stood by his negative vote last month, and said the rest of the commission should do the same.
"Vote with me on this and let the guys try to bring the suit," said Abston. "They've got every right to sue us, let them do it."
Abston made the motion, and it was seconded, but it failed 3-5.
Smartt made the motion for a positive recommendation, which passed 5-3. Abston, Art Giles and Kelly Morgan voted against it.


text:
Print this page
Return to Article
Stop by the Organic Comfort Food Cafe in Puyallup, WA, and you'll be doing something good for your health, and for children close to home and a world away.
Inspired by a mission trip to Cambodia and Vietnam, where she worked with a few orphanages, Patty Rody wanted to do more.
Knowing that America is also home to needy children, Patty wanted to help local foster youth as well as international orphans — providing them "God's comfort and love," she says.
Because she is also passionate about organic food, a restaurant seemed a natural way to raise funds for her mission. So, in December 2007, Patty opened the Organic Comfort Food Cafe.
"I wanted to break the mold of what people expect organic food to be," she says. "So, in addition to traditional organic foods like pure fruit smoothies with no sugar or chemicals, we make everyday comfort food using organic and natural ingredients...like pot pies, meat loaf sandwiches and Beef Stroganoff. In my opinion, you can pay for your health by eating a natural, organic, balanced diet, or by paying health insurance deductibles and hospital bills."
Patty pays employees, utilities and food costs but takes no salary herself. The cafe's goal is printed on the menu, and customers return because they want to support her mission.
"There have been many hurdles along the way," she adds, "but we're doing better than ever now!"
If you or a group you belong to cooks for a charitable, spiritual or other purpose, we'd love to hear from you. Submit your story

subset: commoncrawl


text:
The social network puts a British twist on its site.
Zak Stambor
Pinterest which launched in March 2010, almost immediately attracted international users. But until the social network introduced a British version of its site yesterday, every Pinterest user accessed the same version of the social network.
The social network's U.K. version represents the first step in the social network's broader effort to gain international users by localizing the social network's content, says a Pinterest spokeswoman. France is likely the next country where Pinterest will go local.
Pinterest's British site puts a subtle U.K.-centric spin on the social network. It features British English—for example, the site's humor category is spelled "humour" —and returns search results with more content shared by British consumers than it generally shows on its U.S. site.
Pinterest allows consumers to 'pin' and share favorite products and images from around the web. Consumers then add their pins to boards, which are organizational tools used to group pins together around a particular theme—for example "Tea time."
Pinterest doesn't disclose user numbers, so it isn't clear how many of its users are British or international. But the social network says its goal is to increase its British user base. "We're hoping this will lead to more British pinners discovering things they love on Pinterest," says a Pinterest spokeswoman.
To spread awareness of the changes the social network has revived the social media-focused campaign, called "Pin It Forward," that encouraged influential bloggers to write about the site in 2010. The spokeswoman says that campaign "jump-started the service in the U.S."
In the United Kingdom the social network recruited 300 U.K. bloggers to use Pinterest's U.K. site and write about it on their blogs. The campaign started yesterday.
Each day about 10 bloggers will write about how Pinterest helps them learn about their interests. Pinterest promote those bloggers' posts on its own blog and on other social channels like Twitter.


text:
Type: Improvement
Status: Closed
Priority: Blocker
Resolution: Fixed
Affects Version/s: 2.2.1
Fix Version/s: DEV backlog
Component/s: Repositories
Testing Instructions:
This issue needs a lot of tests.
Changes overview
- File APIs changes to support external files
- Repository APIs changes to serve external files
- Ability to cache external files
- Backup/restore external file entries on same site
- File picker can display iframe inside and pick a file from external repository (equella)
Boxnet repository plugin
- Pick a file from box.net using file reference in editor, save it, and edit it again, make sure no broken files
- Pick a file from box.net without file reference, save it, edit again, make sure no broken files
- Do the same tasks as above in file manager
Dropbox repository plugin
- Pick a file from dropbox repo using file reference in editor, save it, and edit it again, make sure no broken files, check moodledata/cache/filedir, make sure there is a file copy in there
- Do the same task as above in file manager
- Run cron in cli, looking the output, make sure dropbox is checking external files belonging to dropbox
Private files repository plugin
- Pick a file from private files repo plugin using file reference in editor, save it, and edit it again, make sure no broken files
- Do the same task as above in file manager
Server files repository plugin
- Pick a file from server files repo plugin using file reference in editor, save it, and edit it again, make sure no broken files
- Do the same task as above in file manager
File system repository plugin
- Pick a file from file system repo plugin using file reference in editor, save it, and edit it again, make sure no broken files
- Replace the file you previous picked in disk, make sure the file in moodle get updated too, NOTE, chrome caches images very well, make sure you clean all browser caches to reflect changes.
Pick a file reference from private files repo
- Edit your private files, and pick a file from file system repo plugin using file reference
- Make sure that file is viewable in private files tree
- Go to moodle forum, add a new post, pick this file from private area, save it, make sure this file is viewable in forum
- Replace the file from file system plugin in disk, the references in private file area and forum should get updated too
Hide or disable repository plugins
- Hide a repository plugin or instance won't affect external files
- Disable repository plugin or instances, will ask user to copy all external files to local, or do nothing, in case of doing nothing, all external files will be broken
- Backup a course with file references
- And the end of backup process, you should be able to see a warning, "There are file references in this course, they can only be restored in this site"
- Restore a backup package contains file references in the same site, files should be restored and worked
- Restore a backup package contains file references in different sites, at the end of restoring process, you will warned some files cannot be restored because they are references
Choose external files in file picker
This issue needs a lot of tests. Changes overview File APIs changes to support external files Repository APIs changes to serve external files Ability to cache external files Backup/restore external file entries on same site File picker can display iframe inside and pick a file from external repository (equella) Boxnet repository plugin Pick a file from box.net using file reference in editor, save it, and edit it again, make sure no broken files Pick a file from box.net without file reference, save it, edit again, make sure no broken files Do the same tasks as above in file manager Dropbox repository plugin Pick a file from dropbox repo using file reference in editor, save it, and edit it again, make sure no broken files, check moodledata/cache/filedir, make sure there is a file copy in there Do the same task as above in file manager Run cron in cli, looking the output, make sure dropbox is checking external files belonging to dropbox Private files repository plugin Pick a file from private files repo plugin using file reference in editor, save it, and edit it again, make sure no broken files Do the same task as above in file manager Server files repository plugin Pick a file from server files repo plugin using file reference in editor, save it, and edit it again, make sure no broken files Do the same task as above in file manager File system repository plugin Pick a file from file system repo plugin using file reference in editor, save it, and edit it again, make sure no broken files Replace the file you previous picked in disk, make sure the file in moodle get updated too, NOTE, chrome caches images very well, make sure you clean all browser caches to reflect changes. Pick a file reference from private files repo Edit your private files, and pick a file from file system repo plugin using file reference Make sure that file is viewable in private files tree Go to moodle forum, add a new post, pick this file from private area, save it, make sure this file is viewable in forum Replace the file from file system plugin in disk, the references in private file area and forum should get updated too Hide or disable repository plugins Hide a repository plugin or instance won't affect external files Disable repository plugin or instances, will ask user to copy all external files to local, or do nothing, in case of doing nothing, all external files will be broken Backup Backup a course with file references And the end of backup process, you should be able to see a warning, "There are file references in this course, they can only be restored in this site" Restore Restore a backup package contains file references in the same site, files should be restored and worked Restore a backup package contains file references in different sites, at the end of restoring process, you will warned some files cannot be restored because they are references Choose external files in file picker Testing pick a file from equella equella should be displayed fully in file picker window Pick a file from equella repo will get you back the renaming && license selection screen just like other repo plugins
- Testing pick a file from equella
- equella should be displayed fully in file picker window
- Pick a file from equella repo will get you back the renaming && license selection screen just like other repo plugins
Affected Branches:MOODLE_22_STABLE
Pull Master Diff URL:
Documentation link:
Our repository API does not currently support anything beyond hierarchies of simple objects.
Need to support:
- complex objects
- versioned objects
- more metadata
while maintaining security and updatability of files.
As proof of concept develop the Equella module.
Gliffy Diagrams
Issue Links
- caused a regression
MDL-33373 File resource duplication fails on course page
- Closed
- has a non-specific relationship to
MDL-30686 $FULLME should not be used for current page
- Closed
- has been marked as being related by
MDL-32867 Working with external references in filemanager
- Closed
MDL-31901 Changing interface of file picker/manager/browser, use renderers
- Closed
- will be (partly) resolved by
MDL-33032 META: Files UI Stage 1 integrate branch into core
- Closed
- will help resolve
MDL-29158 Review repository code and improve quality and coding standard
- Open
MDL-26454 Implement file references to alfresco repository contents
- Closed
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
While working on file picker API, I need to fix a few file picker bugs too:
File serving issue, shall we cache the repository file all the time when select it in file picker or we streaming the external resources directly?
- Currently in moodle we use send_stored_file to serving files, in the low level, it requires the file ready on disk, stored_file will return a file hander to moodle for file serving, and file size is required by byteserving_send_file()
- When we create a file with external reference, we need to provide a file size to file table, if we don't download the file we don't the the exact file size, we could ask repository plugin, but not all repository plugin could provide this kind of information
The solution I could think of is we store the file locally when user pick a file, then when they request it, file is ready to serve, we can check if the file is up to date at this stage, and download the file then serve it by send_stored_file (this will go through repository plugin, not like normal moodle file of course).
Streaming is preferred, that means pluginfile.php will serve the file while downloading it, I am not sure how to implement it, php cannot do multi-thread, we cannot create one thread download the file and and another on-hold to serving user download. We can create a loop to download 100 bytes each and flush it out to client immediately, I doubt it could be better than downloading the entire file in advance, in this case we have to request partial file and establish http connection costs too.
I just added Eloy to this issue.
Eloy, I updated the repo in my github with backup support, can you please have a look if it's ok? And can you please write some guideline on restoring?
Can you please comment here when you see my message
I added backup support already, now I've to finish the restore, I see there is restore_dbops::send_files_to_pool in backup/util/dbops/restore_dbops.class.php, the problem is I am not sure what's the best way to pass samesite variable, additional parameter results in change all places using restore_dbops::send_files_to_pool. Can you please suggest the best way to do this?
Hi Dongsheng,
I just skimmed some of this code after mention in the meeting the other day and noticed a few things:
- There are some weird bits of whitespace and missing phpdoc which need cleaning up.
- get_system_context should be: context_system::instance();
- The TEXT column sizes have been deprecated in XMLDB - please reload the XMLDB file and generate the new XMLDB upgrade steps without the TEXT column sizes.
- Coding guidelines state no underscores in variables please don't introduce new variables with underscores in them.
Hi Dongsheng,
I'm reopening this and removing it from this weeks integration.
I've just had a quick check of the code and the things that Dan noted earlier haven't yet been fixed (or replied to).
Could you please go over this once more, fix things where required, reply about the rest, and probably run the code checkers over this.
Also once done could you please get Dan (or someone else) to give it a proper pair review as it sounds like Dan has turned those other things up having just skimmed it.
Thanks Dan and Sam
I fixed:
- odd whitespace in code (4 places)
- replaced get_system_context in code
- Updated XMLDB definition and upgrade code
- Removed underscores in my code, NOTE, I'm not being able to fix all underscores in files API, there are probably more than 1000 lines changes, it's very risky
Dan, can you please have another look? As this is a big patch, could please you point out the place you spot issues? It will make it much easier for me to fix it. Thanks
Hi Dongsheng,
Note that comments without punctuation / slight line length warnings are not too important, but great if you do have time to fix up.
The incorrect spacing issues and missing phpdocs are more 'hard rules' for new code.
Dan, I fixed the issues in external-repo-smurf.xml.
btw what's the tool are you using to check coding style per commit?
Thanks Dongsheng - the check is done using marina/tims tool with Jenkins continuos integration server doing the per commit filtering.
Hello guys
Can you submit this to Integration, or it requires more peer reviews?
We are running out time.
This really needs to land urgently. The filepicker work is coming and will need rebasing on top of this.
wait a bit:
1/ $file_record -> $filerecord might be ok according to coding style but it creates and inconsistencies which is hard to review, I personally think that is absolutely not acceptable to be part of this patch and it must be reverted
2/ I sincerely doubt that the foreign key fileid pointing from files_reference to files table is going to work because so far the fileid was NOT supposed to be constant - I guess the reversed link might work better (files table optionally pointing to references)
3/ fileid in files_references should have unique constraint, right?
4/ I do not like the new stored_file->update_record() because it completely changes the API design
5/ $stored_file->repository->send_file() should be handled inside $stored_file->send_file()
6/ I do not think it is necessary to crate second filepool for cache files - technically you could implement that the same way as the image preview david is working on: new hidden file area with special file names, in this case you would use referenceid
7/ $stored_file->repository->send_file($stored_file, $lifetime, $filter, $forcedownload, $filename, $dontdie); followed by die;
8/ it looks like this is either incomplete or buggy because there are no changes in places that can not use referenced files such as assignment - so either it must be disabled by default (is it?) or it is enabled by default and buggy
9/ I do not get how the content getting methods of stored_file are going to work, those extra if ($this->is_external_file())
look like a major pita, I was surprised that stored_file->get_content() did not get it too
10/ there is a code out there that reads files table directly, I guess that is going to break because the records will not contain the repo info, right?
I guess I could continue with more issues if I read the patch properly, I spent only 10 minutes looking at the patch. Sorry if any of my findings or proposals are inaccurate, I did not think much about this, but still my -3 for integration in current state.
Thanks for taking a look, Petr.
1) If the old File API doesn't match coding styles then that is a new bug, I think. Dongsheng did the right thing keeping it consistent originally I think, but if we are going to be anal about coding style checkers then that is the result.
2+ 4) this is pretty crucial to the current functionality. We need to be able to update files, and that was not part of the original design.
6) This way was suggested originally and you (and others) did not want the File API "abused" that way. I am not keen to change it again unless there are very very good reasons everyone can understand.
10) That's why we force the File API, right?
I'll let DS address the rest ...
Hello Petr
I gonna add unique index to file_references table, add send_file interface to $stored_file, and for check all forms in assignment module make sure file linking is disabled.
1) so let's finally fix the style guide, changing unrelated code or doing cleanup as part in one commit with significant API changes is a much much bigger nono which should be immediately rejected by integrators
Anyway I am not going to make problems here, I just want to make known that I strongly disagree with the current patch and I am not going to start fixing any regressions later.
Areas to disable file linking would be:
- assignment submissions content and attachments (because of due dates and grades)
- form posts (because of notifications and threads)
- forum attachments (because of notifications and threads)
- quiz essay questions (because of due dates and grades)
- workshop submissions content and attachment (because of due dates and grades)
Anything else?
yes, anything that deals with the content of files is probably affected because the patch seems to consider mostly pluginfile downloading, anyway my eyes can not see anything because of the unnecessary renaming and docs polishing.
What areas access the content of files uploaded into fileareas? And shouldn't they be doing it via the API anyway?
Latest changes:
- added unique index to files_reference.fileid
- by default, filemanager/filepicker allow create file references, in forum/assignment/workshop, only copying allowed
- stored_file.php: allow external file being downloaed in get_content_file_location function, that means, for example, in course restore, you pick a file from dropbox, and indicate creating a file reference, it will work
- added send_file method to stored_file class, it will call repository to get the file
The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao
1/ the file size of stored_file may be invalid - can cause huge problems for file serving, shortened files
2/ content hash of stored_file may be invalid - this would break etag caching (which I already implemented and tested)
3/ the time modified flag is invalid - breaks not-changed status in file serving
4/ public function get_file_instance() returning false is backwards incompatible, we can introduce exceptions instead of false, but not the other way around
note: I did not do full review, there are probably a lot more problems...
The problem we have here is we don't really have the filesize and contenthash when create file reference, and when files in external repository changes, we cannot detect that then update the db accordingly. It might be not a issue we should worry about, for instance, box.net will give us a secret url for file reference, when moodle serving this file, box.net plugin will redirect user to box.net server, box.net will send etag/modifed-since headers. I understand it's bad for file handing, but I don't know what's the best to get all the correct hash and filesize.
about 4, I will throw exception instead of returning false.
I strongly disagree, all methods of stored_file must imo return valid results otherwise everything gets very messy soon - other APIs start breaking randomly. I believe if you can not get file content then the stuff does not belong to the files table, sorry, file api just can not work without the file content. Technically you could alter all these methods to work properly, that is: each method in stored_file should first look if file is external, then verify lifetime, then fetch new content if necessary and update ALL flags and store the new content in normal file pool. That way it would be 100% accurate, 99% backwards compatible and self contained without any need for second filepool you implemented.
If you need to strictly link only then please, please do it with links or special placeholders in html code that gets post-proccesed by filters.
Petr, we can not copy all the external file content into Moodle. That was exactly the problem with the 2.x design and why everyone hates Moodle 2.x files.
"other APIs start breaking randomly." - that is the detailed info that is needed now.
Wait, this seems to be a misunderstanding, I did not talk about the linking (or better call it synchronisation with repos), I was describing problems in the implementation submitted for integration. I proposed a different implementation that does not break the current file APIs.
Let me sum it up:
1/ you want moodle files to "magically" synchronise with external repositories, right?
2/ I believe the proposed patch breaks the current file API and is inefficient
3/ I think there is a way to implement the necessary changes in a way that is 95% backwards compatible (the 5% is difference being the http caching + performance cost), most of the changes would be directly in stored_file
4/ I can not imagine how could the users fetch files directly from repository without moodle getting the content of the file. It would be extremely hard to do it securely with proper access control and in any case we often need the file content in stored_file for operations such as zipping, csv upload processing, grades import, etc. Also what happens when external system if offline...
5/ Internally it should imo behave like proxy cache with redefined user access control and extra security features (such as forced download). Users would not be in direct browser/http contact with the repository server, all communication would go through moodle server.
Here is my proposal:
- add new fields to files table:
- externalid - linking to table describing the external file (pointing to more file and repository info, more files could link to one external file and bulk synchronise)
- externalverified - last time when synchronised content with ext repo
- externallifetime - how often to sync with ext repo
- add new table for external repository files description - id, repoid, repodata, etc.
- implement automatic content sync in stored_file class, sync would be called before any operation that involves repo file content - content itself, contenthash, time modified, file size.
- add new options for file picker and friends which specifies if links are allowed - UI side only (client side validation)
- add new options for file processing in forms - this would strip all ext links when not supported in given area that does not support later changes of file content such as assignment, workshop, etc. (server side validation)
- add new options for creation of files from existing stored file - strip ext links option
- lower HTTP lifetime of synchronised files and use ETags to prevent repeated sending of file content
My main concern is that you want to push this through integration right before the freeze when it is evident that the patch has major design and implementation problems that can not be fixed in a matter of days. I am not against this new feature, my previous concern was performance and UI issues, that is why I did not want to implement it myself before. After working on file sending last weekend I think the performance should not be a big problem, let's see how the new UI from Marina is able to accommodate the elements necessary for this file sync.
Petr, this is not being pushed through in "days" - it's been under development for months.
You took yourself out of the project at the start. You refused to be involved. You have missed months of discussions about the needs that led to this design, and have chosen to get yourself involved only now. I appreciate your opinion but proposing complete alternative designs now is not helping. The proposal phase is long gone.
The key thing you are missing in your proposal is this: we do NOT always want to store copies of all repository files in Moodle and serve them ourselves. Some will be huge. Some will have copyright restrictions and monitoring requirements. Some will be frequently updated and those updates must propogate instantly. The repository plugin must be allowed to decide where the content is. They may choose to let the repository serve the content directly using their own token systems, perhaps via a CDN. We need to let repositories do what they are designed to do - not cripple them. This is a FUNDAMENTAL criteria.
Please - either help polish this design in 2.3 or don't help at all.
The stored_file as the name suggests deals with files stored in moodle, if you suddenly remove half of the methods or make them return invalid data stuff using it is going to break. Even if you do not have the file contents you need to return valid data from stored_file somehow for our PHP methods, you could lazy download the file form server when necessary. I agree that alternative download via CDN would be nice to have and it does not conflict with my proposal.
If the patch was implemented without bugs and regressions I would keep my mouth shut, but that is not the case and I hope the problems I reported prove it.
if you suddenly remove half of the methods
I don't understand this, stored_file::get_content_file_location will ask repository plugin to download the file if moodle is asking for file's location, so it could handle the external files, but slow.
If the patch was implemented without bugs and regressions I would keep my mouth shut, but that is not the case and I hope the problems I reported prove it.
Yes, it has bugs, I'm fixing while you pointing them out, can we just work together to get this done, not just arguing the design, it has been announced for months, too late to change the whole thing.
Could you make sure all the methods, eg get_filesize(), do the same thing, DS? Just to make sure that repositories are ABLE to satisfy everything that someone might ask for via stored_file. (Whether or not that is technically possible for the repository plugin is up to the repository, of course)
Please try to reconsider the database structure changes, the current 'files_reference' table pointing to files table via fileid seems to me like a major problem because:
1/ it makes $fs->get_file_instance() backwards incompatible because you need to join one more table when getting file record, it does not even seem to try to fetch missing info
2/ if somebody decides we need more columns in file_reference table you need to modify all code again - I suspect there will need to be some more caching info there soon once the repositories start exposing filesize, content, contenthash, etc.
3/ what happens when you create a file from existing linked file? The file_references start multiplicating like rabbits, is that really expected? How is that going to affect performance?
I do not see any valid reason to have this info in separate tables when you only allow one-to-one mapping there and you fetch it in each and every case together and you have to manually keep them in sync at all times. If there was a foreign key in files table pointing to shared file reference table it might open new possibilities in the future.
For the record:
I did not want to work this new feature because the original requirement was to "Allow serving of files without getting the content of files from external repositories by hacking current stored_file class" which is something I have no idea how to implement. A few weeks ago this was submitted for integration and I saw that the implementation actually gets the file content from external repositories - that is a HUGE difference from the original requirement for me. Soon I realised there is a different, relatively clean way to implement this, so I started pointing out the bugs to get your attention and I proposed an alternative implementation which I think has more advanced caching mechanism and better backwards compatibility.
3/ what happens when you create a file from existing linked file? The file_references start multiplicating like rabbits, is that really expected? How is that going to affect performance?
We don't create reference to reference, so when user pick a reference file and saying he want to create a reference to it, repository plugin will find the original file then the new reference will point to the original file directly.
At the very beginning, we was planing to add a new field to mdl_files table, but some developers strongly against this solution, so we moved reference field to separate table, I agree this made stored_file->file_record confusing, but it's really hard to make everyone happy...Petr are you suggesting adding reference field to mdl_files or we store filearea/component/path/filename in references table?
Hmm, this is not about making people happy, this is about code quality and maintainability. Artificial splitting of information into two tables (current approach) is really bad for maintainability, code complexity and backwards compatibility, the fact that it lacks the checks for the missing join in input data is critical because it may result in data loss. The second possible design alternative is to normalise the storage of 'reference' info by creating foreign key in the files table - I do not know if that is better way and what exactly is stored in the reference text field, but it looks like it may get duplicated and hence the database normalisation seems like a good candidate, it would also prevent accidents with missing data in $file_record, it might be also used for caching improvements inside stored_file (we simply need something that identifies the external file that can be searched in database, encoding that info into text field only seems like a bad idea to me, sorry).
Forgive my persistence, but stored_file->update() is really really bad because it does not do any input validation. I can easily imagine it will be the most abused function in file api and will cause bugs and even data loss. Any new developer will just modify stuff there directly without thinking about consequences. Compare it with any create file method in file storage. If you need to do repo specific change please create a new method in stored_file->import_external_file() that does only what you need and does not allow anybody to break everything.
Ho, my 2 cents:
- If really we are getting the files from the repos, then I've nothing against to add one (or multiple) fields to the mdl_files table. Why? Simple, because then they are real "stored" files. As simple as that.
- More yet, if we are getting the files from the repos (external or internal), I think that there are better solutions to keep all copies 100% in sync with source, asking repo each XXX time one file is accessed AND also in an automated way. It would be simply about to allow each file to specify one repositoryfileid pointing to one table where all the information pointing to the file source would be stored. Note it's one 1:n relation, so multiple mdl_files would be pointing to the same repositoryfile->id record. Easy to maintain, sync and without "destroying" the file api. They will be perfect normal and standard stored files.
- You can name those files retrieved from repo whatever you want, proxied files, aliased files... and you can make them to stop working if they are deleted from the source repository. No problem with that. More yet, surely you can redirect browsers to access to the source file in repository when the repository has not "strange" access methods. Or you can serve them from Moodle. Each repo decides.
- The key point here is that it does not break the files API and stored files are always that, stored files. How they are fetched/served and kept on sync is the extra functionality we are addressing here, but without breaking solid concepts.
I'm sure that, if we are really downloading them... we can create "easily" an alternative schema to keep everything working without much disruption.
And once working... it's a matter of expose it with a nice API for repository developers and UI for users. Sounds simple, isn't it?
Dears all, I know it's horribly late and freeze is days away... but really, if we can do it 1) in time and 2) in a better way... then my +1 goes to that.
I was discussing this with Eloy a bit, here are my notes describing potential solution: https://github.com/skodak/moodle/compare/master...repoproxy
Thanks for the code, get_proxy_file_by_reference is pretty much the same as get_file_by_reference, I could integrate your proposals to current patch, I will look into it and post more details here later.
I think you code is still caching everything, yes, it has proxy_readfile in repository, but stored_file->readfile() called too late in send_stored_file function, before it being called, we already cached content to get filesize, and a lot of moodle headers already sent, for simple redirection (most repositories do this), that's too much.
As I said above: We do not always want to store copies of all repository files in Moodle. We can provide a cache facility if the repository wants to support it for efficiency, but they need to also be able to choose not to. This is a requirement.
Dongsheng: you can undo headers if they were not send yet. I did not code this part because it was colliding with my X-Sendfile+ETag patch. So yes, this would need a few lines in readfile_accel() to make it work, I will rebase and add the missing bits.
Martin: the missing content can be implemented via file->status, I will update the patch to illustrate what I mean.
Reopening this guys, sounds like there is still more dev work going on here and we're cleaning up the integration queue.
I copied the function stored_file::update() to my branch, because I also need it.
I noticed that it is not completely correct: you allow to update field only if (isset($this->file_record->$field)). Which means that if field was empty string ('author' in my case), I can never set it to something meaningful.
* Update some file record fields
* @param stdClass $dataobject
public function update($dataobject) {
global $DB;
$keys = array_keys((array)$this->file_record);
foreach ($dataobject as $field => $value) {
if (in_array($field, $keys)) {
$this->file_record->$field = $value;
} else {
throw new coding_exception("Invalid field name, $field doesn't exist in file record");
$DB->update_record('files', $this->file_record);
I integrated your db changes and APIs to record last sync times, added a repository api to return repo file lifetime.
I haven't integrated readfile() method yet, I am not sure what's your plan, currently, it has to cache file all the time, because before calling readfile(), sync_external_file already stored the file in moodle. I don't want to touch the logic in send_stored_file() at this stage yet, we are too close to 2.3 release. Please comment your plan for readfile(), we can discuss it.
Actually, this function is very dangerous. It does not make any checks like in file_storage::
create_file_from_storedfile(), create_file_from_pathname(), create_file_from_string(), create_file_from_url(), etc.
By the way, why there is so much code duplication?
Besides, in stored_file::update() 'timemodified' should be automatically changed if not specified like it happens in
This function is intended to be used by new filemanager, and not being used anywhere else, so feel free change it or start a new one to suits your needs.
Dongsheng, it suits my needs. I can update license and author information using it.
I just wonder that maybe we can write safe code without thinking that "it's only for us"?
It's a public function which means any plugin developer can do serious harm to the file system without even understanding that. "The function exists, so it's safe to use it. Let's change the file component then!".
Added validation to stored_file::update, I am not sure if this is the right place to do it, probably better to create a new method file_storage::update(stored_file $file, $filerecord), and keep stored_file::update simple.
Hi Dongsheng,
this is the new branch that has my changes on top of yours:
Two things I noticed
1. (very critical){"error":"Error writing to database","stacktrace":"* line 416 of \/lib\/dml\/moodle_database.php: dml_write_exception thrown\n* line 955 of \/lib\/dml\/mysqli_native_moodle_database.php: call to moodle_database->query_end()\n* line 997 of \/lib\/dml\/mysqli_native_moodle_database.php: call to mysqli_native_moodle_database->insert_record_raw()\n* line 1271 of \/lib\/filestorage\/file_storage.php: call to mysqli_native_moodle_database->insert_record()\n* line 299 of \/repository\/repository_ajax.php: call to file_storage->create_file_from_reference()\n","debuginfo":"Field 'fileid' doesn't have a default value\nINSERT INTO mdl_files_reference (repositoryid,reference,lastsync,lifetime) VALUES(?,?,?,?)\n[array (\n 0 => 4,\n 1 => 'YTo2OntzOjk6ImNvbnRleHRpZCI7aToxMztzOjk6ImNvbXBvbmVudCI7czo0OiJ1c2VyIjtzOjY6Iml0ZW1pZCI7aTowO3M6ODoiZmlsZWFyZWEiO3M6NzoicHJpdmF0ZSI7czo4OiJmaWxlcGF0aCI7czoxOiIvIjtzOjg6ImZpbGVuYW1lIjtzOjEwOiJGcmFuY2UuanBnIjt9',\n 2 => 0,\n 3 => 86400,\n)]","reproductionlink":"http:\/\/marina.moodle.local\/master\/"}
2. (a suggestion)
I think you should throw an exception either in stored_file::rename or stored_file::update when trying to change filepath/filename to already existing. I check it in my code, but it should be checked in API as well
And also I corrected the declaration of repository::cache_file_by_reference() in .../repository/dropbox/lib.php on line 457 by removing default null for stored file;
it is now the same as in repository_dropbox::cache_file_by_reference()
To help the collaboration here I suggest just working on top of wip-files23, if we need to tidy up commits for integration we can do this at last stage, so lets just fix things on top.
another problem from the mismatching lib/upgrade.php and lib/install.xml:
Notice: Undefined property: stdClass::$referencelifetime in /var/www/repositories/master/moodle/lib/filestorage/file_storage.php on line 856
Error writing to database
More information about this error
Debug info: Unknown column 'referencelifetime' in 'field list'
UPDATE mdl_files SET contenthash = ?, filesize = ?, referencelastsync = ?, referencelifetime = ?, timemodified = ? WHERE referencefileid = ? AND contenthash <> ?
[array (
0 => '905892d700978f5477cc097012429316cf38b4d9',
1 => '6837',
2 => 1336970772,
4 => 1336970772,
5 => '4',
6 => '905892d700978f5477cc097012429316cf38b4d9',
Stack trace:
line 416 of /lib/dml/moodle_database.php: dml_write_exception thrown
line 782 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
line 2170 of /repository/lib.php: call to mysqli_native_moodle_database->execute()
line 468 of /lib/filestorage/stored_file.php: call to repository::sync_external_file()
line 553 of /lib/filestorage/stored_file.php: call to stored_file->sync_external_file()
line 589 of /lib/filelib.php: call to stored_file->get_filesize()
line 334 of /lib/form/filemanager.php: call to file_get_drafarea_files()
line 255 of /lib/form/filemanager.php: call to form_filemanager->__construct()
line 183 of /lib/pear/HTML/QuickForm/Renderer/Tableless.php: call to MoodleQuickForm_filemanager->toHtml()
line 2377 of /lib/formslib.php: call to HTML_QuickForm_Renderer_Tableless->renderElement()
line 403 of /lib/pear/HTML/QuickForm/element.php: call to MoodleQuickForm_Renderer->renderElement()
line 1631 of /lib/pear/HTML/QuickForm.php: call to HTML_QuickForm_element->accept()
line 1407 of /lib/formslib.php: call to HTML_QuickForm->accept()
line 1674 of /lib/pear/HTML/QuickForm.php: call to MoodleQuickForm->accept()
line 435 of /lib/pear/HTML/Common.php: call to HTML_QuickForm->toHtml()
line 204 of /lib/pear/HTML/QuickForm/DHTMLRulesTableless.php: call to HTML_Common->display()
line 889 of /lib/formslib.php: call to HTML_QuickForm_DHTMLRulesTableless->display()
line 658 of /course/modedit.php: call to moodleform->display()
(deleted this comment because it does not reproduce after DB fix)
stored_file::is_external_file() does not seem to work for draft area files.
Below is the dump of stored_file object that is a reference. Field 'repository' is empty, but reference exists (referencefileid, etc. are not empty):
stored_file Object ( [fs:stored_file:private] => file_storage Object ( [filedir:file_storage:private] => /home/marina/web/moodledata/master/filedir [trashdir:file_storage:private] => /home/marina/web/moodledata/master/trashdir [tempdir:file_storage:private] => /home/marina/web/moodledata/master/temp/filestorage [dirpermissions:file_storage:private] => 511 [filepermissions:file_storage:private] => 438 ) [file_record:stored_file:private] => stdClass Object ( [id] => 24041 [contenthash] => 905892d700978f5477cc097012429316cf38b4d9 [pathnamehash] => 0942a22cdf661453e5e5266b758be8e2b6cb349a [contextid] => 13 [component] => user [filearea] => draft [itemid] => 702212956 [filepath] => / [filename] => France.jpg [userid] => 2 [filesize] => 6837 [mimetype] => image/jpeg [status] => 0 [source] => O:8:"stdClass":2:{s:6:"source";N;s:8:"original";s:220:"YTo2OntzOjk6ImNvbnRleHRpZCI7aToyOTY7czo5OiJjb21wb25lbnQiO3M6MTA6Im1vZF9mb2xkZXIiO3M6NjoiaXRlbWlkIjtpOjA7czo4OiJmaWxlYXJlYSI7czo3OiJjb250ZW50IjtzOjg6ImZpbGVwYXRoIjtzOjE6Ii8iO3M6ODoiZmlsZW5hbWUiO3M6MTA6IkZyYW5jZS5qcGciO30=";}
[author] => Admin User [license] => allrightsreserved [timecreated] => 1336971687 [timemodified] => 1336971817 [sortorder] => 0 [referencefileid] => 11 [referencelastsync] => 1336971688 [referencelifetime] => 86400 ) [filedir:stored_file:private] => /home/marina/web/moodledata/master/filedir [repository] => )
stored_file::search_reference_count() returns too many results. Seems that it counts draft area files as well
I created https://github.com/dongsheng/moodle/tree/wip-files23 branch.
There is a new commit 40282b5, that fixed db regression and added more unit tests for draft files
Hi Marina,
That comment isn't quite accurate, moodle will cache JS if $CFG->cachejs is on (setting Appearance > AJAX and Javascript). In that case you'll need to either a) purge caches or b) have a moodle version number increment to get the new file served.
If you have cachejs set to off, then the file will be served directly by your webserver (and expiry headers etc set by it. In this case perhaps we might need to tell the webserver to set cache to expire immediately).
Actually after initially thinking that behavior was silly I understand it now.
Dongsheng, one more comment to your code:
file_storage::get_file_instance says in phpdocs: "@param stdClass $filerecord record from the files table"
Although you actually expect it to be record from files left join files_reference table
I suggest you to change phpdocs and display developer warning if passed object does not have additional fields from files_reference table.
phpdoc changes: c35f42b
I don't think we should warn them, devs are not always create stored_file with reference support.
Seems there are changes in moodleform, not only private files editing form not saved, I just spotted the repository instance editing form not saved too, here is a fix: a9ef861, please integrate.
Dongsheng: it is not a correct fix, the admin/repositoryinstances.php does not set the actual url properly in
should be
admin_externalpage_setup($pagename, '', null, new moodle_url('/admin/repositoryinstances.php'));
I have created new issue for this
I picked Petr's commits in branch wip-files23. There was small merge conflict with the second commit.
I have this hasn't been submitted for integration, but i've started reviewing.
Adding a diff link for reference. Why was this never done before?
Documentation on creating an alias added to the 2.3 docs:
- http://docs.moodle.org/23/en/Working_with_files
- http://docs.moodle.org/23/en/Private_files
- http://docs.moodle.org/23/en/Recent_files_repository
- http://docs.moodle.org/23/en/Server_files_repository
- http://docs.moodle.org/23/en/File_system_repository
- http://docs.moodle.org/23/en/Box.net_repository
- http://docs.moodle.org/23/en/EQUELLA_repository
This issue was assigned to me automatically, however I will not be able to work on this issue in the immediate future. In order to create a truer sense of the state of this issue and to allow other developers to have chance to become involved, I am removing myself as the assignee of this issue.
For more information, see http://docs.moodle.org/dev/Changes_to_issue_assignment


text:
Why The Oilers Should Not Pursue Jay Bouwmeester
Jonathan Willis
May 02 2009 08:59AM
This is Jay Bouwmeester, one of thirty number one NHL defensemen. His exact value is a point of debate in Robin's post below, but it seems fairly safe to say that he's in the top-half of those thirty players. Some would even argue that he's a top-five defenseman.
Regardless, I think he's a luxury the Oilers can't afford; a target created by a fanbase which (like all fanbases) loves the idea of bringing an elite NHL'er to Edmonton. Personally, I don't think the Oilers should even bother pursuing him unless it's clear that playing for the Oilers is a top priority for Bouwmeester. Now, before a lynch mob gathers up their pitchforks and assembles in the comments section, let me explain, because I think there are a number of very good reasons for this mindset.
1. Supply and Demand
How many NHL teams would like to get their hands on Bouwmeester? Let's assume that he's the fifteenth-best defenseman in the league, even though he's almost certainly better than that. This means that at least fifteen teams out there would view him as an upgrade over what they already have. There's going to be a bidding war for his services; there really aren't a lot of high-end defensemen out there, and salary cap or no Bouwmeester's going to be in high demand. In other words, a lot of teams are going to spend their first day of free agency focused on a target they won't end up acquiring while other players are taken off the market. Plus, whoever does grab him will be spending a pile of money, which brings me to my second point:
2. Cap Space
The Oilers don't have it. They were close enough to the cap all season long, and they've got somewhere in the neighborhood of 7-8 million to play with next year. With that money they need to re-sign Denis Grebeshkov, address their lack of a number one goaltender and bring back a bunch of restricted free agents on new contracts. It's going to be tight enough as it is, and the long-term picture isn't any brighter. Even assuming the Oilers were to move one of their higher salaries out of town (Visnovsky or Souray) they'll be taking on more and at this point every dollar matters. Visnovsky and Souray are a nice bridge to my third point:
3. Need
Don't get me wrong: Jay Bouwmeester is a fantastic addition to any hockey club. When looking at the Oilers though, the defense isn't a weak point. The top-four of Lubomir Visnovsky, Sheldon Souray, Tom Gilbert and Denis Grebshkov is one of the best puck-moving units in the league and puck-moving defensemen of that calibre aren't readily available. The Oilers do, however, have a host of problems; I'd contend that keeping the puck out of the net is a major issue but other wish lists have different priorities.
Obviously there's a wide range of opinion among Oiler fans about how to fix the team. However, the one point of consensus that I've heard again and again is that the top-four is the strength of this team, and I don't think there's an argument to be made otherwise. Their numbers:
- Sheldon Souray: 81GP – 23G – 30A – 53PTS, +1
- Tom Gilbert: 82GP – 5G – 40A – 45PTS, +6
- Denis Grebeshkov: 72GP – 7G – 32A – 39PTS, +12
- Lubomir Visnovsky: 50GP – 8G – 23A – 31PTS, +6
There's nothing wrong with that.
To Sum Up
There isn't any question that Jay Bouwmeester could help this hockey team. The fact of the matter is that the Oilers already have a strong top-four, and spending a truck-load of dollars to bring in another high-end defenseman just doesn't make sense when there are so many other more pressing concerns. Fans have been concocting complicated proposals involving signing Bouwmeester and then dealing a defenseman for a top-end forward; it's much simpler to just go after the forward initially, isn't it?
Besides, the Oilers would probably still have a good group of defensemen if they were to trade off one of the top-four and bring in a responsible depth guy to round out the group. Given that there are probably a dozen candidates on the free agent market and more available via trade, that seems to me to be the logical and cap-friendly route for the team to take.
In any case, there hasn't been any real proof that Bouwmeester has a burning desire to come play for Edmonton any more than he wants to play anywhere else. There's been a handful of rumours, from some comments on the ESPN Trade Deadline show to column written by Bruce "Malkin to the Kings" Garrioch. Certainly the player himself hasn't said it, and beyond the fact that he's from Edmonton there isn't much linking him to the team. But even if Bouwmeester were willing to entertain offers from the Oilers, it simply doesn't make sense for the Oilers to make him their number one target in the offseason – make no mistake, that's what it will take for a team to land him – and miss out on opportunities that make more sense for the team.
If Tambi signs J-Bo on July 1, every other GM in the league will know we're up against the cap even worse than before, and will fleece us (ala Pronger) when we're trying to re-arrange assets to make room. I have a hard time thinking he'd let that happen - he'll go after what we do need rather than going after the 'best available' - this isn't the draft. It's a big 'ol chess match...
@ SkinnyD: There are other teams in similar situations. Not saying it would happen, but the Flyers have a need for a puckmoving D and they also have excess scoring forwards making too much coin. If they could distribute their $'s around more evenly, they probably would. A Gagne-Visnovsky deal (likely involving others) could help them achieve that. Then they could dump some smaller bits to create cap room (Randy Jones, Joff Lupul, etc.). That's just 1 example from 1 team. Even if they didn't get equal value, the Oil would still come ahead (a toonie and 2 quarters is more valuble than a loonie and 5 quarters)
Take a run at a healthy Havlat for around 6mil/yr, he managed to stay healthy this year and has mad skills and has developed a nice 2 way game.
I think everybody here should stop thinking JBo is going to come here for anything less than a crazy overpay. It just isn't going to happen. Fer cryin'out loud, this isn't EA sports. Let me say it again for the cheap seats - JBo is NOT coming here for fair value. End of story.
Let's just assume anybody of any decent quality we acquire this summer will be an overpay. Thus, with a decent D already in place, if we're going to get fleeced I'd rather we use our money to go after a decent forward because as Vic has laid out, that's where we're hurting the most.
David S wrote:
Let me say it again for the cheap seats - JBo is NOT coming here for fair value. End of story.
Oh, now that "David S." has spoken from his seat of authority we can all end the conversation now. You should probably call Tambellini as well to make sure he doesn't waste his time by making a phone call to see what kind of money it would take. David S. said end of story.
Look, we are having a conversation about "ifs". We are all well aware of that fact. We are equally aware of the fact that he will likely sign somewhere for too much money. Why does that mean we can't discuss the possibility of his signing, or what the team should do if it turns out to be a possibility? Are you saying you've never discussed anything hypothetical before?
My favorite part of your post was how you, at the end, express a preference to being fleeced by a forward. What is the difference? If we are overpaying we are overpaying. At least if we overpay him by 1.5 million we can still get some scoring and our D gets younger. If we overpay a forward by 1.5 all we get is the scoring and our defense is as old and brittle as ever.
If you want to act like an authority of some kind at least try not to discredit your own argument at the end of your post.
So fat the only reasonable argument I have seen against is the one which mentioned that if he gets signed then other GM's know we need to move some defense, yet even that has been addressed.
David S wrote:
Thus, with a decent D already in place, if we're going to get fleeced I'd rather we use our money to go after a decent forward because as Vic has laid out, that's where we're hurting the most.
So how is getting "fleeced" for a forward any better than getting "fleeced" for a defenseman AND THEN moving a current defenseman for a forward of equal cap value? If you pay 7 mil for a forward OR pay 7 mil for a defenseman AND THEN trade a 5.6 mil (ish) defenseman for a 5.6 mil (ish) forward - ITS THE SAME THING. And I'm not even suggesting that the forward would make that necassarily (although I've suggested about 5.25-Simon Gagne, not a big diff).
I'm not deadset on signing J-Bo at all cost, but I think if its a reasonable option, its a no-brainer.
kingsblade wrote:
We are all well aware of that fact. We are equally aware of the fact that he will likely sign somewhere for too much money.
Your words, not mine. A "hypothetical" involves speculation about something that MIGHT be possible. What I'm saying is that JBo won't be coming here for anything close to "fair value", something you yourself agree with. Thus the hypothesis doesn't hold and the conversation becomes like a bunch of drunk guys repeating the same thing over and over. "Brodziak and Staios for Malkin. Beer me."
RossCreek - I see where you're coming from. But I still don't think JBo will ever be a reasonable option. There's just way too much hungry money out there this summer. Besides, Souray would make a f*ck of a C, something we sorely need. Not sure, but doesn't Souray have a NTC?
David S wrote:
Besides, Souray would make a f*ck of a C, something we sorely need. Not sure, but doesn't Souray have a NTC?
The 5.6 reference was to Visnovsky, not Souray (5.4).
Having said that, here's an off-the-wall thought: What if instead of all the Gilbert (and to a lesser extent - Grebeshkov) talk, the Oil instead chose to keep those 2 for age reasons and instead move BOTH Souray & Visnovsky. Obviously this would only be if Bou signed here AND if you could replace the toughness void that moving Souray (and Staios)would create. One could be moved for a top 6 forward, while the other could be moved for some much needed prospects to restock the shelves. Essentially, it would be like the old song - Money For Nothing - the Oil wouldn't take that big of a hit on the backend (if at all), plus they would add a scoring forward & prospect(s), all the while keeping the young core of the team intact (something I'd argue, although not that strongly, they may have messed up in moving guys like Stoll, Torres & Greene, regardless of whom was received in return).
In any case, I'm NOT saying that I'd go this route for certain, but maybe its a bit of a different approach to think of. Heck, why not think of every different possibility no matter how "ridiculous" they may seem at first. Exhaust all avenues in your brain before coming to a conclusive decision. This scenario would likely have even more question marks than the previous, but its something to at least think about, no? I myself may decide this approach would be stupid down the road, but right now I'm not sure I'd dismiss much - there's lots of time before the decisions turn to actions.
And to those who didn't like the approach of moving 2 of the top 4 D-men before, obviously I don't expect you to change your views now (although the logic seems flawed if you're willing to move Gilbert as things currently stand, but not willing to move 2 of the top 4 if a guy like Bouwmeester were added - if you're willing to move 1 of the top 4 now, why wouldn't you be willing to move 2 of the top 4 if you add a #1?)
May 03 2009, 12:25AM
kingsblade wrote:
Are you claiming that they now cannot negotiate with multiple players at the same time? He would be a pretty poor GM if he only talked to one player at a time.
So you fax a 1yr, 6MM contract offer over to MArian Gaborik, and a 5 year, 32.5 MM contract offer to Bouwmeester. Both accept. You can't possibly fit both in without massive rearrangements, and everyone knows you're up the creek without a paddle so they lean on you hard (like Anaheim found out when the tried to move first MacDonald and then again when they tried to move Schneider).
@ Jonathan Willis: So your saying you'd rather make the commitment to an oft-injured player on a 1 year deal than to a homegrown stud on the backend that vitually plays half the game and could anchor the blueline in eTown for the next 10 years??
Your logic makes SOME sense but your example is piess poor.
As soon as an offer was accepted by 1 player, the offer could be pulled from the other player. Chances they agree at the exact same moment - slim (unless they have the same agent, I suppose). The deal would still have to be signed & verified, so its not exactly like they'd get "stuck up the creek without a paddle". I'm sure a team can back out of a deal if a player can (Nylander), although that may not look all that good.
I would pretty much trade anyone but Hemsky, Gagner and Cogliano for Bouwmeester, but that being said a worthwile top 3 forward should be the first priority. I still hope for Kovalchuk
David S wrote:
Thus the hypothesis doesn't hold and the conversation becomes like a bunch of drunk guys repeating the same thing over and over. "Brodziak and Staios for Malkin. Beer me."
HA! I love it when guys think that we can trade our garbage for gold. Why discuss it if will NEVER happen? On a totally unrelated note, I've got to go pick Halle Berry. We're going to meet Evangeline Lilly for shooters.
blackmud wrote:
I would pretty much trade anyone but Hemsky, Gagner and Cogliano for Bouwmeester, but that being said a worthwile top 3 forward should be the first priority. I still hope for Kovalchuk
You don't have to trade anyone for Bouwmeester. He's a 25 year old Unrestricted Free Agent (unprecedented, as he's the 1st 25 year old in this position, if I'm not mistaken).
RossCreek wrote:
You don't have to trade anyone for Bouwmeester. He's a 25 year old Unrestricted Free Agent (unprecedented, as he's the 1st 25 year old in this position, if I'm not mistaken).
Technically speaking, Scott Hartnell would've been in this position a couple years back, but he didn't make it to July 1st to hit the open market, as he was traded to Philli and signed in late June.
I cannot think of anyone else to hit UFA at 25 (but that doesn't mean there wasn't).
Jonathan Willis wrote:
There's two legitimate number one d guys on the market (JBo and Zubov)
Here's the top UFA D-men available this summer IMO: Jay Bouwmeester Mike Komisarek Mattias Ohlund Francois Beachemin Derek Morris
Here's some that aren't likely to move, or if they do, likely have a specific destination or 2 in mind (OLDER GUYS): Scott Niedermeyer (possible he's open to anything, but I'd bet on Ducks, Devils or Canucks) Mathieu Schnieder (veteran nearing end, not sure where he'll end up-Philli?) Sergei Zubov (injury-plagued season, superstar likely nearing the end; can't see him leaving Dallas if he is to play next season) Rob Blake (also nearing end, can't see him leaving California)
Bouwmeester is easily without a doubt the best defenceman available, and even if his intentions were good (he'd like to come home for reasonable $'s), he's likely to get a few offers that "blow him away". If he takes 6-7 from the Oil, no hesitation on my part to sign him. If he's looking for 7-8, you'd probably have to pass.
David S wrote:
A "hypothetical" involves speculation about something that MIGHT be possible. What I'm saying is that JBo won't be coming here for anything close to "fair value", something you yourself agree with. Thus the hypothesis doesn't hold...
This is gold. Are you really trying to tell me what hypothetical means? Are you really pretending that you are the authority on what might happen? One of my favorite things about sports is looking at possible transaction scenarios and discussing how they could play out. I agreed that he likely will sign for too much, not that he will certainly sign for too much, and So what if it's not that likely to happen. It's a reasonable point of discussion here for everyone but you.
Besides my other point still stands - wouldn't you rather get fleeced for a franchise defenseman than a transient mercenary scorer.
...and if you are really trying to argue against this because Souray would make a great captain (although you had a much classier way of putting it) the I submit that the last thing this team needs is to make a captain out of the guy who wouldn't talk to the media at the end of the season. I also thing you are severely overvaluing the captaincy.
Jonathan Willis wrote:
kingsblade wrote: Are you claiming that they now cannot negotiate with multiple players at the same time? He would be a pretty poor GM if he only talked to one player at a time. So you fax a 1yr, 6MM contract offer over to MArian Gaborik, and a 5 year, 32.5 MM contract offer to Bouwmeester. Both accept. You can't possibly fit both in without massive rearrangements, and everyone knows you're up the creek without a paddle so they lean on you hard (like Anaheim found out when the tried to move first MacDonald and then again when they tried to move Schneider).
You can't be serious. It is pretty common practice to write conditions into contract offers. First, you don't need to be sending signed contracts without some sort of verbal confirmation. Second, even if you did send them signed you just make them conditional on other contract offers not being accepted first. It's a very basic contract term. Like when you offer to buy a house but make it conditional on obtaining the financing first.
I think that a guy as good with numbers as you would consider this possibility, so I have to think you were willfully ignoring it when you made this argument.
I'm completely on side with Willis. I read through the posts quick so maybe I'm not the first person to mention this: Why is everyone so eager to turnover the defence? They are a pretty good group as is. Why move TWO of your top four? Isn't there some value in continuity?
@ Chris: Please read the thread. I think pretty much every argument for both sides has been played out already.
Chris wrote:
Why is everyone so eager to turnover the defence?
I don't think its that everyone is so eager. I think its looking at things with an open mind - If you cannot add the top 6 forward through free agency, (and even if you can), a better option might be to trade for him. If so, a defenceman may be the trade bait, especially if you can add a top 10 D via free agency (someone that would be a definate upgrade on what they currently have, both in the now and future).
May 03 2009, 03:21PM
@ kingsblade:
No, you missed my point a bit I think. You manage to get Bouwmeester inked. The teams already over the salary cap to make this move if you've re-signed any RFAs - suddenly that top-six forward who is willing to sign with you either isn't able to (only allowed to exceed the cap by 10%) or he puts you in the situation I just outlined - with a massive payroll and the need to dump money, and everybody knowing it.
@ kingsblade:
I did read the thread, though quickly...
Almost everything pitched by everybody involved signing J-Bo and using one of the other top four to aquire atop six forward... Willis is right. The Oilers don't have room under the cap to accomplish this. The only way to get J-Bo inked under the cap would involve a) Trading one of the current top four for a Forward. b) And then trading another top four guy for a cheaper D-man to play top four minutes. I think this would not only be difficult for Tambellini to do; it would be counterproductive as well. I don't see how J-bo + some other cheaper D-guy + Grebs + one of Gilbert/Souray/Visnovsky is a massive upgrade. I also don't think it is wise to turn over two of your top four. I just don't like the thought of Grebs having to play top four minutes with a player who costs 2Mil or so.
@ Jonathan Willis: So even if you don't get fair market value by trading a d-man, would it not be better to land Bouwmeester+ rather than remain status quo? I mean assuming you couldn't land 1 of the top UFA forwards. Bouwmeester is clearly better than what the Oil currently have. Now. And in the future.
If you have the option of keeping Visnovsky OR signing Bou and trading Visnovsky for 2/3's value (if it came down to it!), its a no-brainer. Heck, if you signed Bou and traded Vis for zero return (which is less than they'd receive obviously), you'd be better off making the moves. Not only is Bouwmeester better than what the Oil currently have, but he IS a top 10 (or better) now, and he will be a top 10 (better) for the next decade. This whole argument is based on getting him at 7 ish or less and him wanting to be here (and although I've argued so much in favor of signing him, I have SOME doubts as to whether or not he'd thrive in this environment-how long til fans booed this "overpayed jerk" for not putting up 80 points?).
His size, skill, age & ability to play tough minutes (half the game) makes him worth more than anything else the Oil have. If his attitude and willingness to come home match the rest of the package, he's worth it. There is more than the common statistics to his game. If his shy demeanor makes him hesitant to play at home (and management would know this), then maybe you pass. Otherwise, it'd be a great move.
Jonathan Willis wrote:
@ kingsblade: No, you missed my point a bit I think. You manage to get Bouwmeester inked. The teams already over the salary cap to make this move if you've re-signed any RFAs - suddenly that top-six forward who is willing to sign with you either isn't able to (only allowed to exceed the cap by 10%) or he puts you in the situation I just outlined - with a massive payroll and the need to dump money, and everybody knowing it.
If you have already inked Bouwmeester than you now have the assets necessary to trade for a top 6 forward. You don't need to sign one.
Needing to trade players dot not preclude getting value when the players you have to move are good puck moving defensemen. There are enough teams out there that need one of what we have that getting a top 6 guy for someone like Souray should not be a problem.
Will they get a player as good as Souray? Doubtful, but they will still be ahead of the game as far as assets are concerned while making the defense younger and will still have improved up front.
I guess a lot of this debate also comes down to team building and differing philosophies about how it should be done. I am a believer in having that franchise defenseman who defines the team. Detroit has Lidstrom. Anaheim won a cup with Neidermeyer. Dallas had Zubov. Colorado had Bourque or Blake, take your pick. Jersey had Neidermeyer. The Rangers had Leetch.
Every team with a cup inthe last 15 years, except for Carolina and Tampa, had a franchise defenseman. I believe we need one too.
The best defensemen we have currrently are going to be quite old by the time this team has a chance at competing for a cup, but Bouwmeester could be that franchise defenseman that we need. He could be that guy for 10 years, rather than the few injury riddled seasons left to Souray and Visnovsky.
Souray has a high trade value right now. It can only go down from here, so why not maximize our assets and take advantage while we can?
who cares if you move a player for under market value is you're adding an upgrade? Let and Eastern team be the benefactor of a sugary sweet deal and let us improve our team.
kingsblade wrote:
Anaheim won a cup with Neidermeyer... Every team with a cup inthe last 15 years, except for Carolina and Tampa, had a franchise defenseman. I believe we need one too.
Tampa did have Dan Boyle. And I like how you "conveniently"(?) left out Pronger's name.
Everyone here has seen 1st hand what having a stud top notch D-man can do for an average team (Roli helped too). I don't get why you wouldn't want Bouwmeester here (unless he doesn't want to be here).
@ kingsblade: ^^ The 2nd part above was not aimed directly at you. It was to all.
RossCreek wrote:
Tampa did have Dan Boyle. And I like how you "conveniently"(?) left out Pronger's name.
Yeah, I thought about including him but most people consider him a step below those other guys. As you say, including him supports the argument even more but I left him off to avoid arguments about whether he was a franchise quality defenseman. Pronger's name was left off because it was unnecessary as he was the second one on the team, and because he's an a$#hole. (and not because of the trade demand out of Edmonton but because he has always been one)
In short, it appears to be difficult to win a cup without a franchise defenseman. For those that wish to elevate Souray or Visnovsky to that level I have just one question - even if they are that good now will they still be when this team is finally ready to contend?
The team needs to be looking at what it needs long term for a cup, not just what it needs to improve a bit for the next year or two.
@ kingsblade:
Wouldn't it be best to draft your franchise defenceman? Other than Peckham did the Oilers draft ANY of their D? This is really at the heart of the problem. It takes several key components to win a cup... The Oilers will always be up against the cap; and a few pieces short unless MacGregor can find "impact" players later in the draft. (Tall order I know.) I want Tambellini to sign Hossa. I want Tambellini to sign J-bo. I want Tambellini to take a run at Luongo after next year... The reality is: Tambellini is committed to $35 million in payroll with only 11 players under contract for 2010/11. Many analysts agree that the cap is most likely to reflect the current economic downturn THAT season... How good do you think the Oilers are going to be with around 70% of thier cap allotted to 11 players... most of whom will be underperforming thier contracts? It's time to look at a salary dump and proper rebuild...NOT signing expensive UFA's to long term contracts. Lowe left this team in a bit of a mess IMO.


text:
Accredited Sales Diploma£19 instead of £495 (from The Shaw Academy for Business Psychology) for an online sales course with accredited diploma - save 96%
Save 96%
Time left to purchase
- Take an online sales course.
- Learn about communication techniques and common pitfalls.
- Plus building rapport through speech and body language.
- Accredited diploma upon completion.
- 24/7 access with no time limit.
The Fine Print
- May buy multiples.
- Voucher valid for redemption until 28th May 2014.
- Subject to availability.
Full Details
If you've ever been thrown the classic 'sell me this pen' interview question and struggled to come up with reasons other than 'it's a biro' and 'has a lid', take a page out of today's deal...
We're offering you an online sales course with accredited diploma for just £19, saving you 96% off The Shaw Academy for Business Psychology's price of £495 (correct as of 10.5.14).
The Wolf of Wall Street's Jordan Belfort may have been a corrupt and crooked character, but no one can deny he was an excellent salesman. Like Belfort, The Shaw Academy for Business Psychology understand that miscommunication means missed sales, which is why they've compressed their knowledge into an online course for you to study at your own convenience. The course covers topics from common pitfalls to building costumer rapport through speech and body language, providing a great basis from which you can step into the science of sales and art of persuasion. You'll learn to frame an argument and present evidence as well as understand the role that emotions play in sales.
- Course content:
- Module 1: Introducing persuasion for sales
- Module 2: Rapport (conversation)
- Module 3: Rapport (body language)
- Module 4: The 6 principles of persuasion
- Module 5: Your tools
- Module 6: Asking questions
You'll have lifetime 24/7 access to course materials with Q&A sessions throughout the programme. Upon successful completion of the sales course, you'll receive a diploma certificate to commemorate your new sales swagger. Next stop, Wall Street!
How to Redeem
- When the deal ends we'll send you your unique wowcher code.
- Head to The Shaw Academy for Business Psychology's site using the link we send you.
- Enter your wowcher code when prompted.
Once purchased, you can redeem this wowcher towards another wowcher or claim a Wowcher Wallet Credit. Click here for more info.
4 Duck Feather & Down Pillows£18.99 instead of £127.99 (from Adam Linens) for four duck feather hotel quality pillows - save 85%
Save 85%
Time left to purchase


text:
(1) Has actual knowledge of it;
(2) Has received a notice or notification of it; or
(3) From all the facts and circumstances known to the person at the time in question, has reason to know that it exists.
(b) "Knowledge" means actual knowledge. "Knows" has a corresponding meaning.
(c) "Discover", "learn", or words of similar import refer to knowledge rather than to reason to know.
(d) A person "notifies" or "gives" a notice or notification to another person by taking such steps as may be reasonably required to inform the other person in ordinary course, whether or not the other person actually comes to know of it.
(e) Subject to subsection (f), a person "receives" a notice or notification when:
(1) It comes to that person's attention; or
(2) It is duly delivered in a form reasonable under the circumstances at the place of business through which the contract was made or at another location held out by that person as the place for receipt of such communications.
(f) Notice, knowledge, or a notice or notification received by an organization is effective for a particular transaction from the time it is brought to the attention of the individual conducting that transaction and, in any event, from the time it would have been brought to the individual's attention if the organization had exercised due diligence. An organization exercises due diligence if it maintains reasonable routines for communicating significant information to the person conducting the transaction and there is reasonable compliance with the routines. Due diligence does not require an individual acting for the organization to communicate information unless the communication is part of the individual's regular duties or the individual has reason to know of the transaction and that the transaction would be materially affected by the information.
Note: WV Code updated with legislation passed through the 2016 Regular Session
The West Virginia Code Online is an unofficial copy of the annotated WV Code, provided as a convenience. It has NOT been edited for publication, and is not in any way official or authoritative.


text:
Sports Business Research Network includes full-text articles from 14 sports-business related publications, as well as over 2,500 tables covering participation, attendance, consumer expenditures, and market shares for 34 sports and fitness activities. Another feature is directory information for amateur and professional sporting organizations, venues, trade associations, etc.
More Options:
Classic Catalog |
OhioLINK |
Online Journals/Resources |
Lane Public |
WorldCat |
More Options:
Research by Subject |
Databases A-Z
More Options:
OhioLINK Home |
OhioLINK Catalog |
Research by Subject |
Databases A-Z
More Options:
Miami University Search |
Miami University Directory
4th Annual Album of Year Poll Winner - Beyonce's Lemonade
Albums not Available on Spotify
Zines in the Community
I Heart Reading: New February Leisure Titles