creadur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Suárez Sánchez <ssm...@gmail.com>
Subject Re: [GSOC] Rat: Past, Present and Future
Date Wed, 10 Jul 2013 22:49:14 GMT
>
> 1. scan the source, building a strongly-typed, immutable domain model


This point is basic to improve the project because now there aren´t a good
domain model and it´s very confused.

Scanning could be done multithreadedly with a status output on console


This is a very good improve but maybe it will make the project more
complex. Apache-rat-core is the base and it will need to be clear and hardy.

* using more conventional dependency injection (see, for example,
> http://www.martinfowler.com/**articles/injection.html<http://www.martinfowler.com/articles/injection.html>)
> replacing the static methods that litter the code
> * immutable domain objects with builders


Static is dead, in the actual world all of developments is orientated to
injection,one of the most important java framework is SPRING so all the
functionality can be injected and you can change in runtime.

However, I think that the current streaming design isn't particularly
> intuitive or obvious. I would be happy to retain an improved streaming
> design.


I think that apache rat is a release audit tool, focused on licenses. In
the project you analyse a file(audio) and you get the license of the file. Why
do you try to use streaming/message driven architecture?

Manuel.


2013/7/9 Robert Burrell Donkin <robertburrelldonkin@blueyonder.co.uk>

> On 07/08/13 21:41, sebb wrote:
>
>> On 8 July 2013 20:46, Robert Burrell Donkin
>> <robertburrelldonkin@**blueyonder.co.uk<robertburrelldonkin@blueyonder.co.uk>>
>> wrote:
>>
>
> <snip>
>
>
>  2. analyse this model against policies, building a strongly-typed,
>>> immutable
>>> report model
>>>
>>
>> Won't that require lots of memory?
>>
>
> Not sure about lots (the state required should be relatively small) but
> yes, more
>
>
>  At present the source can be forgotten as soon as a match occurs.
>>
>
> Perhaps
>
> An architecture where each document flowed through the system is likely to
> be more efficient and easier to parallelism.
>
> However, I think that the current streaming design isn't particularly
> intuitive or obvious. I would be happy to retain an improved streaming
> design.
>
> Robert
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message