Jon Stevens wrote:
> UNIQUE IDENTIFIER (Rafal):
>
> Uh. Why is this exactly needed? Seems like unnecessary overhead as computing
> a MD5 hash is expensive. Could you please give more details about this? I am
> _very_ wary of adding code to Turbine.java...so anything added there *must*
> be under extremely defined purposes and *must not* be something that could
> be implemented elsewhere. If anything, this should be optionally defined in
> the TurbineResources.properties file as a boolean (default: false) so that I
> can turn it off.
I primarily needed it for generating server-wide unique names for temporary
files - that would not clash among multiple instances of Turbine running on
the same machine and possibly writing temorary files to a single directory.
Then I thought that it may be more generaly usable, beacuse MD5 of the addres
you are visible under has overwhelmning chance to be unique worldwide. Suppose
your application stores user's preferences somewhere outside it (say, in an
LDAP server). It can use it's identifier to access them afterwards. At the same
time, someone who has access to those data is unable to tell to what application
these preferences belong (MD5 is one way) thus protecting the privacy of the user.
The identifier is computed exactly once, on the first hit to your application,
wich makes me think that we needen't to be concerned with the overhead.
Currently my upload code uses this identifier. It could be well replaced with
File.createNewFile() method but unfortunately its JDK 1.2+. If someone has an
idea how to avoid clashing filenames among muliple threads possibly running
in multiple JVMs using JKD 1.1 please let me know. (Neeme/Olegs FileHandler
did this terribly wrong, it would even freeze one of Turbine therads if two
of them would attempt crating a temp file in the same system clock quantum.)
I just thought that unique ID for a Turbine instance would be good.
OT: Dropping Jserv & JDK 1.1 compatibilty will be a great day for Turbine.
It will allow us to wipe out *tons* of cruft.
> FILE UPLOAD:
>
> Do not worry about relying on the O'Reilly file upload code. I work with
> Jason Hunter, the author of the code. It really isn't an issue as I can just
> buy him a beer to resolve things. :-) Rafal, go ahead and check in your
> changes. I appreciate that you like to post them on your site first, but
> most people don't have the time to download them and check them out first. I
> would much rather see your code in CVS and read the commit logs and then
> complain about it later. :-) Luckily, your commits are 99.99% great so there
> are few complaints I think.
I don't have any problems with using O'Reilly uploader. I turned
util.upload.UploaderOReilly
class into services.upload.OReillyUploadService and it should work just fine.
I'll commit my changes soon. I tested it, my teammate (whose module needed file
upload) tested
this also, and Jeff Brekke promised to test it for me. If he doesn't find anything
serious,
I'll check it in ASAP.
> LDAP:
>
> +1. Implement it as a service.
Uh, we already have an LDAP service, TurbineNamingService. I don't know what
it does exactly but this is probably everthing we need to create User interaface
implementation that uses LDAP as data backend. We could also take a look at JAAS
(Java Authorization and Authentication Services) that is freely available from Sun.
It has Solaris, Windows NT and LDAP backends.
I hope that someone with more LDAP knowledge will step out and take care of this.
(I remeber that Manik Surtani was looking for an assignment, Manik how do you feel
about learing JNDI/LDAP?)
-------------------------------------------------------------------------------------
I'd like to recap some things that I proposed earlier.
RENAMING SERVICES
I proposed to drop 'Turbine' prefix on service names (requires changing TR.prpoperties
in ALL EXISTING
instalations) and SERVICE_NAME constants in all service interfaces. This would
emphasize the
pluggable nature of services - e.g. you request any implementation of
'WebMacroService' not necesserily
Turbine default implementation. Them, we could also make BaseServiceBroker to insist
that a class that
is given as implentation of service named 'x' implements an interface that has a name
ending in '.x'.
In case of broken configuration (wrong implementation class) an informative error
message would appear
in the log instead of 'ClassCastException' in your code where you retireve the service.
MOVING Turbine class to org.apache.turbine
to be Java standards compliant, for clarity and to make Javadoc happy.
As I uderstand this creates an issue with JServ and is postponed until we decide to
drop
JServ compatibility.
Rafal
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
