The Possible New Future for Mobiles

Reading the article at:
http://www.wirelessdesignmag.com/news/2013/01/what-if-microsoft-threw-its-weight-behind-mozillas-firefox-os?et_cid=3042288&et_rid=506719374&linkid=http%3a%2f%2fwww.wirelessdesignmag.com%2fnews%2f2013%2f01%2fwhat-if-microsoft-threw-its-weight-behind-mozillas-firefox-os

some topics stand out:

Recently (and ironically) Microsoft bought all of Netscape’s patents from AOL for $1 billion. These include such foundational patents of the web as Secure Socket Layer (SSL), cookies and JavaScript.

One motivation for Microsoft’s acquisition of Netscape’s patents could be to use them in a patent war with Google to stop the Chrome browser’s ascendance in its tracks. The mobile version of Chrome will be a major competitor to Apple’s Safari as well as Mozilla’s new Firefox OS.

The Mozilla entry is not only a browser, but a full-on operating system that can run mobile devices.

The Netscape technology bought by Microsoft, possibly trying to stuck Chrome, and the Firefox OS, supplying support for resources which were before just supplied by the operating system, lead us to a future completely different from the present.
The operating system will no more define the mobile market, split into Android, Apple and Microsoft.

You will buy connectivity considering cost/benefit (ROI – return on investiment) and the O.S. will become a secondary subject, or even optional.

The new Market will fight offering the best final resources under the users’ point of views, where the way to achieve them is no more relevant.

The new rules will change the IT scenarios as a consequence in just few years like a Tsunami, considering that a new embedded O.S. may offer some concepts inherited from the virtual machines were additional O.S. compliances and services may be available to the applications, turning the native O.S. transparent and no more decisive.

Better considering such possibility when planning at long term.

Thunderbird - Inbox is full

If you get the message that your Inbox is full when you start thunderbird, check the following:

1. Open thunderbird as usual, ignore the warning and check all the inbox folders for those accounts that are pop and not imap type. To discover the type, go to  menu, tools, account settings, and point an account,
then "Server Settings" and check on the right the "Server Type" on the top, close to the tittle.

Let all pop accounts' input folders empty, moving their contents to another folder or deleting it.
Once the pop inbox folders are empty, close thunderbird.

2. If desired, check your server's inbox using a web email through your browser or use an imap account version in thunderbird. In such cases,  probably you'll find find the emails that were not downloaded to your machine because the local input folder was considered full, but they are still there, on the server, waiting to be downloaded.

Note: An imap account differs from pop because the former access you email on the server and latter downloads the server content to your machine, saving on the local repository.

3. Go to your local repository, the place where you save your emails in your machine.

Note: If you don't know this place, you can find it clicking on menu, tools, account settings, on the left panel point to local folders then on the right you get your local repository path into the local directory input box.

There you're gonna find two files and one folder:

Inbox.mozmsgs (folder)
Inbox
Inbox.msf

Delete the Inbox and the Inbox.msf files, and start thunderbird again but at this time the warning shall have gone.

Note: thunderbird will recreate those files automatically when restarted, fixing the problem.


IMPORTANT:

If you have any important email that you can't find in you inbox, check it first on the server's input box.
If you still didn't find it, than instead of performing the procedure above, create a new local repository,
switching the path (see note on the 3rd step and just set a new temporary path).
Restart thunderbird and check again. If found, you can return to the original path, execute the procedure above and then you manually move the files downloaded to the temporary repository, created before, to your usual local repository.

Value Object vs. DTO

This subject is a controversial issue.
Check different sources below.

Reading the different definitions, I think that :

- Value Object are simple objects passed by value.

- DTO are tranfer objects, so serializable.

- Depending on the context, both may have same meaning, as referred by the J2EE documentation below, when a Transfer Object is passed by value or treated like so, but they do not represent the same concept.
 
- Summarizing:

  A DTO is linked to the concept of its pattern.
 
  A Transfer Object is an object that servers the purpose of a wrapped data transport object.
  So, it can be used in DTO pattern or anywhere else.
 
  A Value Object is a small simple object not based on identity, but on its values' equality.
   
    Depending on the context, things can assume the same role, so they seam similar on its purpose but not on their natures.


----------------------------------------------------------------------------------------------------------------------------------------------

Entity beans aren’t serializable.
We find that we must define additional data transfer objects (DTOs, also called value objects) when we need to transport data to a remote
client tier.
The use of fine-grained method calls (multiple method calls) from the client to a remote entity bean instance is not scalable.
DTOs provide a way of batching remote data access.
The DTO pattern results in the growth of parallel class hierarchies, where each entity of the domain model is represented as both an
entity bean and a DTO.

Use a Transfer Object to encapsulate the business data.
A single method call is used to send and retrieve the Transfer Object.
When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with
its attribute values, and pass it by value to the client.

Clients usually require more than one value from an enterprise bean.
To reduce the number of remote calls and to avoid the associated overhead, it is best to use Transfer Objects to transport the data from
the enterprise bean to its client.

When an enterprise bean uses a Transfer Object, the client makes a single remote method invocation to the enterprise bean to
request the Transfer Object instead of numerous remote method calls to get individual attribute values.
The enterprise bean then constructs a new Transfer Object instance, copies values into the object and returns it to the client.
The client receives the Transfer Object and can then invoke accessor (or getter) methods on the Transfer Object to get the individual
attribute values from the Transfer Object.
Or, the implementation of the Transfer Object may be such that it makes all attributes public.
Because the Transfer Object is passed by value to the client, all calls to the Transfer Object instance are local calls instead of remote
method invocations.

FROM:
http://java.sun.com/blueprints/corej2eepatterns/Pattern/TransferObject.html


  My Note: 
Within this context, it makes sense to assume Value Object as synonym to Transfer Object , because the Transfer Object is passed by value to the client.
Outside this context, a "Transfer Object" is not necessarily a "Value Object" cause instead of being passed by value it may contains references or representations.

Setback
If the Transfer Object comes like a big ship navigating up and down, other problems are raised - throughput (network traffic) and memory usages.
See Adam's comment, below on his blog.

----------------------------------------------------------------------------------------------------------------------------------------------
Data transfer object (DTO) is a design pattern used to transfer data between software application subsystems.
DTOs are often used in conjunction with data access objects to retrieve data from a database.

The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except  for
storage and retrieval of its own data (accessors and mutators).

In a traditional EJB (Enterprise JavaBeans) architecture, DTOs serve dual purposes:

First, they work around the problem that entity beans  pre-ejb 3.0 are not serializable;

Second, they implicitly define an assembly phase where all data to be used by the view are fetched and  marshalled into the
DTOs before returning control to the presentation tier.

A third reason of using DTOs could be that  certain layers of the
application should not be able to access the underlying data access objects, and hence change the data.

A value object is a small simple object, like money or a date range, whose equality isn't based on identity.

FROM:
http://en.wikipedia.org/wiki/Data_transfer_object
http://en.wikipedia.org/wiki/Value_object

----------------------------------------------------------------------------------------------------------------------------------------------


A value object is a small simple object, like money or a date range, whose equality isn't based on identity.

FROM:  Wikipeadia


----------------------------------------------------------------------------------------------------------------------------------------------


The pattern which is known today as Data Transfer Object was mistakenly (see this definition) called Value Object in the first version of the Core
J2EE Patterns.
 
The name was corrected in the second edition of the Core J2EE Patterns book, but the name alue Objectbecame very popular and is still used as an
alias for the actual DTOs.
 
There is, however, a real difference between both patterns: A Data Transfer Object (DTO) is just as stupid data container which is used to transport
data between layers and tiers.
It mainly contains of attributes.
 
Actually you can even use public attributes without any getters / setters, but this will probably cause too much meetings and discussions :-).
 
DTOs are anemic in general and do not contain any business logic.
DTOs are often java.io.Serializable - its only needed if you are going to transfer the data across JVMs.
 
A Value Object [1,2] represents itself a fix set of data and is similar to a Java enum.
A Value Object doesn't have any identity, it is entirely identified by its value and is immutable.
A real world example would be Color.RED, Color.BLUE, SEX.FEMALE etc.
@FROM:
Adam's blog