Menu
▾
▴
bodington-developers — Mailing list for Bodington developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(41) |
May
(353) |
Jun
(133) |
Jul
(534) |
Aug
(401) |
Sep
(219) |
Oct
(86) |
Nov
(144) |
Dec
(61) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(200) |
Feb
(130) |
Mar
(345) |
Apr
(153) |
May
(247) |
Jun
(338) |
Jul
(222) |
Aug
(70) |
Sep
(39) |
Oct
(27) |
Nov
(76) |
Dec
(30) |
| 2007 |
Jan
(81) |
Feb
(44) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(34) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(6) |
| 2008 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Peter C. <Pet...@me...> - 2006-03-01 12:09:00
|
> From: Matthew Buckett > The session layer likes nulls as the mime type and so when transfering > files you can set the mime type to null but as the database layer > doesn't like this it always gets mapped onto an empty string. Ah, OK - hadn't spotted that I could hand in a null. > Maybe we should change this so that the database layer deals=20 > with nulls? > This would simplify some of the code but as you mentioned requires > dropping the constraint that mime_type of uploaded_files=20 > can't be null. That seems like a better approach to me, but the SQL for the migration code is probably hairy. - Peter |
|
From: Matthew B. <mat...@ou...> - 2006-03-01 12:00:07
|
Matthew Buckett wrote: > Peter Crowther wrote: > >>>From: Matthew Buckett >>>If the uploaded file has a mime type set >>>we use that otherwise we use the mimetype mapper. >> >> >>Looks like you've not made any schema changes, and that a mime-type >>length of 0 causes the type to be deduced? > > > Yep. A fuller explanation: The session layer likes nulls as the mime type and so when transfering files you can set the mime type to null but as the database layer doesn't like this it always gets mapped onto an empty string. Maybe we should change this so that the database layer deals with nulls? This would simplify some of the code but as you mentioned requires dropping the constraint that mime_type of uploaded_files can't be null. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Matthew B. <mat...@ou...> - 2006-03-01 11:45:12
|
Peter Crowther wrote: >>From: Matthew Buckett >>If the uploaded file has a mime type set >>we use that otherwise we use the mimetype mapper. > > > Looks like you've not made any schema changes, and that a mime-type > length of 0 causes the type to be deduced? Yep. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Peter C. <Pet...@me...> - 2006-03-01 11:33:37
|
> From: Matthew Buckett > If the uploaded file has a mime type set > we use that otherwise we use the mimetype mapper. Looks like you've not made any schema changes, and that a mime-type length of 0 causes the type to be deduced? - Peter |
|
From: Matthew B. <mat...@ou...> - 2006-03-01 11:06:08
|
Peter Crowther wrote: >>From: Matthew Buckett >>I have work to this effect on WebLearn HEAD that didn't go across to >>Bodington in the uploaded file changes. I changed this so that when a >>file is uploaded we don't store the mime type at all and the when the >>file is returned to the client we use the mapping available from the >>servlet container to determine the mime type. This is not an ideal >>solution but is one step better. > > > Yes please! Pushed across. I have tried to seperate the servlet mime type mapper from the buildingserver layer. If the uploaded file has a mime type set we use that otherwise we use the mimetype mapper. Newly uploaded files don't have a mimetype but existing files continue to be served up with their stored mime types. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Adam M. <ada...@co...> - 2006-02-28 17:09:41
|
We're putting together a set of use cases for what we want out of the tracking service. The scenario is a Bodington with WAFFLEy bits attached, eg, MVN, a wiki, chat maybe, LUSID all working under some sort of SSO, think WebAuth or Shibb. What sort of tracking would a tutor want? Please give us some use cases, the more the merrier. You can jot them down in note form if you like and I'll tidy them up later. I have attached what we have so far (from our soon-to-be-accessible public wiki). Ignore the edit button! Just send plain text either to me or to the list if you feel it warrants further discussion. Remember, if you don't pipe up now, we may not cover your favourite tracking scenario. adam -- Adam Marshall: OUCS, 13, Banbury Rd. Oxford OX2 6NN. Shameless plug 1: Use the Bodington VLE http://bodington.org Shameless plug 2: Use the LUSID PDP system, http://www.lusid.org.uk/ Blog: http://ramble.oucs.ox.ac.uk/blog/adamm/ Cheese of the month: Korbacik - Slovakian String Cheese |
|
From: Adam M. <ada...@co...> - 2006-02-28 16:51:42
|
| -----Original Message----- | From: bod...@li... [mailto:bodington- | dev...@li...] On Behalf Of Selwyn Lloyd | Sent: 28 February 2006 14:08 | To: bod...@li... | Subject: Re: [Bodington-developers] Subversion (SVN) @ sourceforge.net. | | Hi all, | | Something we have found trickier to deploy has been bugzilla, so far | installed but not exactly working... anyone got any first hand | experience of configuring bugzilla... or suggestions for a non perl | alternative? | | At this point I expect someone to groan at me and say use the source | [source forge] for all this stuff and again 'using SF' is seemingly a | strong bordering on mandatory advisory coming out of the toolkits | programme... SF does have the tools and support OS project need, you can even mount your own software, eg, a wiki, on the SF site. BUT (and it's a bigger but than J-Lo plus Big Butt Bertha squeezed into a single seat) - its so blinkin' unreliable and slow. The wiki we uploaded to the bod site was completely unusable and from time to time (although luckily not at a critical point), it becomes impossible to connect. | | We have our own cvs at the moment and I guess we need to revisit the | source forge approach... but I really don't like the way that source | forge brings an element of wierdness to open source development such as | 'competition'. What do you mean? | | Would any others be interested in forming a development cooperative so | we can reduce costs of development, test bed and pilot | infrastructure?... something which AFAIK SF does not really provide... | We have been looking at the costs of 'external racks' and considering | offering hosting services on a rack to other projects to help us cover | the underlying costs but being partners in a cooperative would suit us | just fine. We already have these facilities here I'm afraid! adam | | Ideally we would be aiming towards a cooperative mirrored service of | some description with more than one rack in more than one location... | | Selwyn | | | | | | | Paul Davis wrote: | | >Just come out of a meeting and it seems Oxford's systems team have a | script | >which converts from CVS to subversion, should we decide to move over | >Paul | > | >------------------------------------------------------------------------- | >Dr Paul V Davis | >Acting Head, Learning Technologies Group | >Project Manager, WebLearn ( Oxford's version of Bodington.org) | >Oxford University Computing Services | >13 Banbury Road, Oxford, OX2 6NN | >Tel: 01865 283414 | > | > | > | > | > | >-----Original Message----- | >From: bod...@li... | >[mailto:bod...@li...] On Behalf Of | >Alexis O'Connor | >Sent: 28 February 2006 10:54 | >To: bod...@li... | >Subject: [Bodington-developers] Subversion (SVN) @ sourceforge.net. | > | >Subversion (SVN), the version control system is now hosted at | >sourceforge.net. The suggestion has been mooted in the recent past to | >use this instead of CVS as it is the natural successor and although very | >similar to use, is superior in a number of ways. | > | >Any migration would not be imminent and there is the port from CVS to | >handle, but just a pointer that this is now possible. | > | >(Incidentally, we've opted to use svn @ sf.net for our TReCX project). | > | > | > | | | | ------------------------------------------------------- | This SF.Net email is sponsored by xPML, a groundbreaking scripting | language | that extends applications into web and mobile media. Attend the live | webcast | and join the prime developer group breaking into this new coding | territory! | http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 | _______________________________________________ | Bodington-developers mailing list | Bod...@li... | https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Alexis O'C. <ale...@co...> - 2006-02-28 14:58:54
|
Selwyn Lloyd wrote: > Hi all, > > Phosphorix just stuck subversion on our cvsd server [cvs.ionode.org]... > we would are interested in figuring out the overhead of porting our > current cvs source to svn... as its currently the case that we are using > eclipse + cvs and this works well for us. > There are various tools around for converting from CVS to SVN such as cvs2svn (http://cvs2svn.tigris.org). Comrade buckett gave it a spin on the WebLearn source and he said that it seemed to work OK. Subclipse (http://subclipse.tigris.org) is an SVN plugin for Eclipse, which is the client I'll be using. As an aside, as open-source projects go, Subversion has exemplar documentation. Alexis |
|
From: Peter C. <Pet...@me...> - 2006-02-28 14:21:23
|
> From: Selwyn Lloyd > I'm mindfull also that "SVN is the best" may be a view=20 > the rest of the community hold. Subversion is the *newest*, not necessarily the best. It's got a useful mix of features between cvshome (which is very conservative in the features it offers) and CVSNT (which has lots of features but can have stability problems). We use an old and stable CVSNT in-house, but I can see that the mix of features+stability could make SVN a compelling alternative. > Something we have found trickier to deploy has been bugzilla, so far=20 > installed but not exactly working... anyone got any first hand=20 > experience of configuring bugzilla... or suggestions for a non perl=20 > alternative? Mantis. We were surprised how easy it was to configure, but it's less feature-rich than Bugzilla. It's worth taking half an hour to look at, though. > We have been looking at the costs of 'external racks' and considering=20 > offering hosting services on a rack to other projects to help=20 > us cover=20 > the underlying costs but being partners in a cooperative=20 > would suit us just fine. Yeah, we're in about the same situation, but I suspect our rack requirements would be lower than yours and we probably wouldn't go mirrored. - Peter |
|
From: Selwyn L. <sel...@ph...> - 2006-02-28 14:08:10
|
Hi all, Phosphorix just stuck subversion on our cvsd server [cvs.ionode.org]... we would are interested in figuring out the overhead of porting our current cvs source to svn... as its currently the case that we are using eclipse + cvs and this works well for us. Subversion might offer us as way to host 'released' or more mature open source projects so a script to port stable releases from our cvs might be helpful... leaving us our cvs for projects going through internal development perhaps... I was a bit surprised when we were advised to use SVN and not CVS on the grounds that you can't rename stuff in CVS and SVN is easier to use and do stuff with. I'm mindfull also that "SVN is the best" may be a view the rest of the community hold. The SVN service is not top of the agenda for us unless JISC/CETIS further advise us that it is a must do for the open source maturity aspect of a 'toolkit' and in our case the ioMorphWS toolkits. Something we have found trickier to deploy has been bugzilla, so far installed but not exactly working... anyone got any first hand experience of configuring bugzilla... or suggestions for a non perl alternative? At this point I expect someone to groan at me and say use the source [source forge] for all this stuff and again 'using SF' is seemingly a strong bordering on mandatory advisory coming out of the toolkits programme... We have our own cvs at the moment and I guess we need to revisit the source forge approach... but I really don't like the way that source forge brings an element of wierdness to open source development such as 'competition'. Would any others be interested in forming a development cooperative so we can reduce costs of development, test bed and pilot infrastructure?... something which AFAIK SF does not really provide... We have been looking at the costs of 'external racks' and considering offering hosting services on a rack to other projects to help us cover the underlying costs but being partners in a cooperative would suit us just fine. Ideally we would be aiming towards a cooperative mirrored service of some description with more than one rack in more than one location... Selwyn Paul Davis wrote: >Just come out of a meeting and it seems Oxford's systems team have a script >which converts from CVS to subversion, should we decide to move over >Paul > >------------------------------------------------------------------------- >Dr Paul V Davis >Acting Head, Learning Technologies Group >Project Manager, WebLearn ( Oxford's version of Bodington.org) >Oxford University Computing Services >13 Banbury Road, Oxford, OX2 6NN >Tel: 01865 283414 > > > > > >-----Original Message----- >From: bod...@li... >[mailto:bod...@li...] On Behalf Of >Alexis O'Connor >Sent: 28 February 2006 10:54 >To: bod...@li... >Subject: [Bodington-developers] Subversion (SVN) @ sourceforge.net. > >Subversion (SVN), the version control system is now hosted at >sourceforge.net. The suggestion has been mooted in the recent past to >use this instead of CVS as it is the natural successor and although very >similar to use, is superior in a number of ways. > >Any migration would not be imminent and there is the port from CVS to >handle, but just a pointer that this is now possible. > >(Incidentally, we've opted to use svn @ sf.net for our TReCX project). > > > |
|
From: Paul D. <pau...@ou...> - 2006-02-28 13:05:03
|
Just come out of a meeting and it seems Oxford's systems team have a script which converts from CVS to subversion, should we decide to move over Paul ------------------------------------------------------------------------- Dr Paul V Davis Acting Head, Learning Technologies Group Project Manager, WebLearn ( Oxford's version of Bodington.org) Oxford University Computing Services 13 Banbury Road, Oxford, OX2 6NN Tel: 01865 283414 -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Alexis O'Connor Sent: 28 February 2006 10:54 To: bod...@li... Subject: [Bodington-developers] Subversion (SVN) @ sourceforge.net. Subversion (SVN), the version control system is now hosted at sourceforge.net. The suggestion has been mooted in the recent past to use this instead of CVS as it is the natural successor and although very similar to use, is superior in a number of ways. Any migration would not be imminent and there is the port from CVS to handle, but just a pointer that this is now possible. (Incidentally, we've opted to use svn @ sf.net for our TReCX project). -- + - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Alexis O'Connor, VLE Developer (http://bodington.org) | | OUCS, 13 Banbury Road, Oxford, OX2 6NN, UK. | | Tel. +44 (0)1865 283661 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - + ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Bodington-developers mailing list Bod...@li... https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Alexis O'C. <ale...@co...> - 2006-02-28 10:54:27
|
Subversion (SVN), the version control system is now hosted at sourceforge.net. The suggestion has been mooted in the recent past to use this instead of CVS as it is the natural successor and although very similar to use, is superior in a number of ways. Any migration would not be imminent and there is the port from CVS to handle, but just a pointer that this is now possible. (Incidentally, we've opted to use svn @ sf.net for our TReCX project). -- + - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Alexis O'Connor, VLE Developer (http://bodington.org) | | OUCS, 13 Banbury Road, Oxford, OX2 6NN, UK. | | Tel. +44 (0)1865 283661 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - + |
|
From: Matthew B. <mat...@ou...> - 2006-02-25 12:52:05
|
Jon Maber wrote: > I just tried listing Facility.java from source forge's web view onto the > CVS repository. > > It's too big! Yep. :-( > After the first few pages the CPU on my laptop when to 100% and the > cooling fan pumped up to full rpm. After ten minutes I had to turn off > the central heating in my flat. Editing Facility in an IDE can also be interesting if your machine isn't nice and shiny. > Could be a Firefox memory leak in the style sheet routines but for all > sorts of other reasons Facility.java is too big. I'm guessing that some > people have made changes that improve the situation (Matthew?) but these > aren't rolled into the HEAD of the CVS yet. I extracted the style sheet code (~2000 lines) into a seperate class which makes it a little more manageable but it's still too big. > So, do we have a list of refactoring attempts that people have > implemented locally and might like to share for testing? There are some other smaller changes on WebLearn HEAD that aren't on Bodington but none of them seriously affect the size of Facility. I've been trying to open up the WebLearn CVS/SVN so that anyone can see what is/has been happening with it but it's been taking a while. I'll try and chivey things along on Monday. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Jon M. <jo...@te...> - 2006-02-24 18:36:32
|
I just tried listing Facility.java from source forge's web view onto the CVS repository. It's too big! After the first few pages the CPU on my laptop when to 100% and the cooling fan pumped up to full rpm. After ten minutes I had to turn off the central heating in my flat. Could be a Firefox memory leak in the style sheet routines but for all sorts of other reasons Facility.java is too big. I'm guessing that some people have made changes that improve the situation (Matthew?) but these aren't rolled into the HEAD of the CVS yet. So, do we have a list of refactoring attempts that people have implemented locally and might like to share for testing? Jon |
|
From: Peter C. <Pet...@me...> - 2006-02-24 18:11:05
|
> From: Matthew Buckett > I have work to this effect on WebLearn HEAD that didn't go across to > Bodington in the uploaded file changes. I changed this so that when a > file is uploaded we don't store the mime type at all and the when the > file is returned to the client we use the mapping available from the > servlet container to determine the mime type. This is not an ideal > solution but is one step better. Yes please! Peter |
|
From: Jon M. <jo...@te...> - 2006-02-24 16:53:04
|
Matthew Buckett wrote: >Jon Maber wrote: > > >>Perhaps a better scheme would be as follows; >> >>1) default null entry in mime_type field of database when files uploaded. >>2) servlet uses servlet container configuration to determine MIME type >>if database field says NULL. >>3) servlet uses value in database if it isn't null BUT may ignore if >>it's on a system-configured banned list of MIME types. >> >> > >WebLearn is at this point, except we don't have the banned list. Shall I >merge this code across? > > I would vote in favour but only +1 because I think it probably is more a question for those who are at the sharp end of the problem like Peter. Jon |
|
From: Matthew B. <mat...@ou...> - 2006-02-24 16:49:56
|
Jon Maber wrote: > Perhaps a better scheme would be as follows; > > 1) default null entry in mime_type field of database when files uploaded. > 2) servlet uses servlet container configuration to determine MIME type > if database field says NULL. > 3) servlet uses value in database if it isn't null BUT may ignore if > it's on a system-configured banned list of MIME types. WebLearn is at this point, except we don't have the banned list. Shall I merge this code across? > 4) On the manage uploaded files page we add functionality to change mime > type. > > Then in most cases and for most users the mime_type field in the > databaes can be left null but if they need to change it they can > (usually to support a rarely used plugin or helper or to cope with > ambiguous extensions like .rpm). If left null, file name changes will > result in a change to the delivered MIME type automatically. We recently hit the powerpoint problem again because we (the container) were setting the mime type to something other than the one for which you coded a fix in BuildingServlet. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Jon M. <jo...@te...> - 2006-02-24 16:39:14
|
Perhaps a better scheme would be as follows; 1) default null entry in mime_type field of database when files uploaded. 2) servlet uses servlet container configuration to determine MIME type if database field says NULL. 3) servlet uses value in database if it isn't null BUT may ignore if it's on a system-configured banned list of MIME types. 4) On the manage uploaded files page we add functionality to change mime type. Then in most cases and for most users the mime_type field in the databaes can be left null but if they need to change it they can (usually to support a rarely used plugin or helper or to cope with ambiguous extensions like .rpm). If left null, file name changes will result in a change to the delivered MIME type automatically. Jon Matthew Buckett wrote: >Peter Crowther wrote: > >At the moment there is some code I believe that uses a static set of >mime type extensions to map to mime types which are used when unpacking >ZIP file at the session layer. See the webpublish.mime.ext.* bodington >properties. > >This code isn't used though when uploading a zip file as the unpacking >is done by facility. I think stuff like the IMSCP does use it though. > > > >>>From: Jon Maber >>>You could present the user with a list of file extentions used in the >>>zip file mapped to the MIME types that were assigned and provide a >>>little form to change them. >>> >>> >>Yes, I could. That's not the issue at present; the issue is how (and >>even whether) to deduce the MIME-types to be assigned. At present, it >>would seem that passing a null mime_type around is acceptable - >>presumaly that causes the type to be deduced from the file suffix on >>download? >> >> > >For single uploads you can get the mime type from the client as someone >else mentioned. But the multipart parser doesn't currently look for this >ot store it anywhere I think (time to pull in commons-upload?). > >I have work to this effect on WebLearn HEAD that didn't go across to >Bodington in the uploaded file changes. I changed this so that when a >file is uploaded we don't store the mime type at all and the when the >file is returned to the client we use the mapping available from the >servlet container to determine the mime type. This is not an ideal >solution but is one step better. > >On WebLearn you can still discover the mime type at the session layer as >we have a mimetype mapper as depending on the mime type depends on >wether you wish to filter the file. > >Storing the mime type has some problems, what do you do if someone >changes the extension of a file after uploading it? This can be a very >nice way to get around filters ;-) > > > |
|
From: Matthew B. <mat...@ou...> - 2006-02-24 16:25:24
|
Peter Crowther wrote: At the moment there is some code I believe that uses a static set of mime type extensions to map to mime types which are used when unpacking ZIP file at the session layer. See the webpublish.mime.ext.* bodington properties. This code isn't used though when uploading a zip file as the unpacking is done by facility. I think stuff like the IMSCP does use it though. >>From: Jon Maber >>You could present the user with a list of file extentions used in the >>zip file mapped to the MIME types that were assigned and provide a >>little form to change them. > > > Yes, I could. That's not the issue at present; the issue is how (and > even whether) to deduce the MIME-types to be assigned. At present, it > would seem that passing a null mime_type around is acceptable - > presumaly that causes the type to be deduced from the file suffix on > download? For single uploads you can get the mime type from the client as someone else mentioned. But the multipart parser doesn't currently look for this ot store it anywhere I think (time to pull in commons-upload?). I have work to this effect on WebLearn HEAD that didn't go across to Bodington in the uploaded file changes. I changed this so that when a file is uploaded we don't store the mime type at all and the when the file is returned to the client we use the mapping available from the servlet container to determine the mime type. This is not an ideal solution but is one step better. On WebLearn you can still discover the mime type at the session layer as we have a mimetype mapper as depending on the mime type depends on wether you wish to filter the file. Storing the mime type has some problems, what do you do if someone changes the extension of a file after uploading it? This can be a very nice way to get around filters ;-) -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Jon M. <jo...@te...> - 2006-02-24 16:12:27
|
Sorry - I misunderstood your original message. Could you explain what the problem is a bit more? Peter Crowther wrote: >>From: Jon Maber >>You could present the user with a list of file extentions used in the >>zip file mapped to the MIME types that were assigned and provide a >>little form to change them. >> >> > >Yes, I could. That's not the issue at present; the issue is how (and >even whether) to deduce the MIME-types to be assigned. At present, it >would seem that passing a null mime_type around is acceptable - >presumaly that causes the type to be deduced from the file suffix on >download? > > - Peter > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 >_______________________________________________ >Bodington-developers mailing list >Bod...@li... >https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > |
|
From: Peter C. <Pet...@me...> - 2006-02-24 16:06:53
|
> From: Jon Maber > You could present the user with a list of file extentions used in the=20 > zip file mapped to the MIME types that were assigned and provide a=20 > little form to change them. Yes, I could. That's not the issue at present; the issue is how (and even whether) to deduce the MIME-types to be assigned. At present, it would seem that passing a null mime_type around is acceptable - presumaly that causes the type to be deduced from the file suffix on download? - Peter |
|
From: Jon M. <jo...@te...> - 2006-02-24 16:04:43
|
You could present the user with a list of file extentions used in the zip file mapped to the MIME types that were assigned and provide a little form to change them. Jon Peter Crowther wrote: >>From: Jon Maber >>In some sense the MIME type of a file is the responsibility >>of the user that uploaded it >> >> > >True, but not necessarily useful if the system is unzipping a Zip file >and attempting to deduce a MIME type for each entry. > > - Peter > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 >_______________________________________________ >Bodington-developers mailing list >Bod...@li... >https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > |
|
From: Peter C. <Pet...@me...> - 2006-02-24 16:01:45
|
> From: Jon Maber > In some sense the MIME type of a file is the responsibility=20 > of the user that uploaded it True, but not necessarily useful if the system is unzipping a Zip file and attempting to deduce a MIME type for each entry. - Peter |
|
From: Jon M. <jo...@te...> - 2006-02-24 15:54:45
|
P.S. regardless of RMI, SOAP and scaling up to clusters I still think it is good practice to put data processing and data presentation in separate sets of Java classes. Jon Jon Maber wrote: > The trouble with evolution is it gives the Giraffe a nerve that goes > all the way down its neck only to do a u turn and go back up, and it > gives us appendices that get infected and kill us. On the other hand > we get great things like eyes and consciousness.... > > The intention was to produce a system that could be closer and closer > to enterprise java beans architecture (bodington predates EJB specs > but was influenced by the early planning of it). That way the > 'business' logic could be spread over a cluster of servers and the web > server could run in a separate process with users spread over multiple > httpd servers. However, that seems to have been a bit of a dead end in > the evolution of Bodington. > > Thinking logically, in a system which might split tool sessions and > http session across RMI or some other kind of remote procedure call > like SOAP, perhaps it really is the back end tool session that should > choose which MIME type a file is when it stores in in the repository > of files and NOT the http session. > > In some sense the MIME type of a file is the responsibility of the > user that uploaded it - they will reasonably expect the system to > assign a meaningful MIME type if they don't express a preference but > they might want to assign their own personal file extension to MIME > mappings and they might want to make wildcarded, recursive changes to > the MIME type of existing files. > > Jon > > > Peter Crowther wrote: > >> So here I am trying to transfer all the files from a zip into a pigeon >> hole. Just like the rest of the upload, it's done in the session. Then >> I realise I need the MIME types of files with specified suffixes. No >> problem, there's an easy way to get that... In the facility, which is >> potentially the wrong side of an RMI interface. >> >> Has anyone else had to deal with this? >> >> - Peter >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting >> language >> that extends applications into web and mobile media. Attend the live >> webcast >> and join the prime developer group breaking into this new coding >> territory! >> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Jon M. <jo...@te...> - 2006-02-24 15:52:05
|
The trouble with evolution is it gives the Giraffe a nerve that goes all the way down its neck only to do a u turn and go back up, and it gives us appendices that get infected and kill us. On the other hand we get great things like eyes and consciousness.... The intention was to produce a system that could be closer and closer to enterprise java beans architecture (bodington predates EJB specs but was influenced by the early planning of it). That way the 'business' logic could be spread over a cluster of servers and the web server could run in a separate process with users spread over multiple httpd servers. However, that seems to have been a bit of a dead end in the evolution of Bodington. Thinking logically, in a system which might split tool sessions and http session across RMI or some other kind of remote procedure call like SOAP, perhaps it really is the back end tool session that should choose which MIME type a file is when it stores in in the repository of files and NOT the http session. In some sense the MIME type of a file is the responsibility of the user that uploaded it - they will reasonably expect the system to assign a meaningful MIME type if they don't express a preference but they might want to assign their own personal file extension to MIME mappings and they might want to make wildcarded, recursive changes to the MIME type of existing files. Jon Peter Crowther wrote: >So here I am trying to transfer all the files from a zip into a pigeon >hole. Just like the rest of the upload, it's done in the session. Then >I realise I need the MIME types of files with specified suffixes. No >problem, there's an easy way to get that... In the facility, which is >potentially the wrong side of an RMI interface. > >Has anyone else had to deal with this? > > - Peter > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 >_______________________________________________ >Bodington-developers mailing list >Bod...@li... >https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > |
19 messages has been excluded from this view by a project administrator.
