In this section we describe an application that allows users to have stick-ers that may be sent over the network through the centralized and semi-centralized implementations of LuckyJ (sections 5.2 and 5.3). This applica-tion was originally designed to provide a soluapplica-tion for having virtual Sticky Notes10 that would, (1) be evolvable (2) run anywhere. It is only after a while that we thought that it could be an interesting feature to be able to go further than just having stickers on local computers, thus we added the behavior needed to send stickers over the network.
10This is inspired by the Software Notes application made by 3-M (consult http://www.3m.com/market/office/postit/com prod/psnotes/index.html for more de-tails).
6.3. COLLABORATIVE VIRTUAL STICKY NOTES 119 In a first part we describe the general architecture of our stickers applica-tion. In a second part we explain in details services and interactions between the entities that compose our stickers application. Finally, in a third part, we give some development feedbacks as well as some explanations on how this application could be extended and used to build a groupware application.
6.3.1 General Architecture
In this subsection, we describe the general architecture of our stickers appli-cation. An important point to notice is that we wanted to be able to send stickers over the network to other stickers users.
LuckyJDescriptionPasser
LuckyJ Platform
LJServiceManager
PostItManager
FileSystemEntity PostIt *
1 2' n
PostItManager PostItManager
PostItManager
* *
n n
m
Figure 6.6: Stickers Application General Architecture.
EachPostItentity represents a sticker (see figure 6.7). Users may change the sticker’s color, save the sticker’s text, read the sticker’s text from a file or send the sticker to another PostItManager.
Each PostItManager is an entity that gives a name to PostIt entities and allows to manage them (see figure 6.8). The PostItManager holds a name given by default to users login but may be changed through the use of the name button. Users may add some stickers (through the use of the + button), remove some stickers managed by this PostItManager (through the use of the - button) or update some stickers (through the use of the % button). It may also receive copies of remote stickers.
120 CHAPTER 6. PROGRAMMING WITH LUCKYJ
Figure 6.7: A Sticker.
Figure 6.8: A PostItManager.
The FileSystemEntity is mainly an unmodified version of the WeeselJ web server version.
At first the platform loads a PostItManager (see figure 6.6). When the user adds a sticker, thePostItManager loads a PostIt entity (step ① invokes a sticker’s service to fix its name (step②
add a sticker, remove a sticker, update a sticker, save/read a sticker from the file system or send a sticker to another (or the same) PostItManager (step n), in this last case, another sticker is then created, managed by the other PostItManager.
The distribution feature is simply obtained by using one of the distributed implementations of LuckyJ (see chapter 5 for more details). This means that our application may work as a personal sticker program, when the local implementation of LuckyJ is used, or as a workgroup stickers program when
6.3. COLLABORATIVE VIRTUAL STICKY NOTES 121 a distributed implementation is used.
6.3.2 Entities and Services
In this paragraph, we describe in more details services that are used in our stickers application. In a first part we show service descriptions belonging to PostIt entities. In a second part, we show service descriptions belong-ing to PostItManager entities. We do not detail service descriptions for the FileSystemEntity as they are mainly the same as for the WeeselJ’s FileSystemEntity.
PostIt entity’s Services
The PostIt entity announces two different services: a service to give the name of the sticker itself and a service to transfer the state of a remote sticker to a newly created sticker.
The service to give the name of the sticker at load time is described as follows:
//code for announcing the naming service
LJDescriptionObject fname[] = {new LJString("F"),
new LJString("Configuration"), new LJString("Name"),this.id};
LJDescriptionObject bname[] = {new LJString("B"), new LJString()};
LJDescriptionObject qname[] = {new LJString("Q")};
LJServiceDescription sdname = new LJServiceDescription(
new LJTree(fname), new LJTree(bname),
new LJTree(qname), 3, 2, 1);
return this.register(sdname);
Note that in this service description we use the tag that identifies (this.id) thePostIt entity. This is correct because thePostItentity has been loaded by the PostItManager that is in charge of it. Thus, the only entities that may send a message to thePostIt entity through this service are either the PostItManager itself the PostItentity itself, or an entity mandated by one of those to do so.
The service to transfer the state of a (potentially remote) sticker to this one:
//code for fixing parameters
LJDescriptionObject fname[] = {new LJString("F"),
new LJString("Configuration"),
122 CHAPTER 6. PROGRAMMING WITH LUCKYJ
new LJString("state"),this.id};
LJDescriptionObject bname[] = {new LJString("B"), new LJString()};
LJDescriptionObject qname[] = {new LJString("Q")};
LJServiceDescription sdname = new LJServiceDescription(
new LJTree(fname), new LJTree(bname),
new LJTree(qname), 4, 2, 1);
fixState_=this.register(sdname);
Once again, in this service description we use the tag that identifies the PostItentity. This service is used (as the previous one) at load time (actually just after loading) to give to a newly loaded PostIt entity, the parameters of the sent PostIt.
PostItManager entity’s Services
The PostItManager registers only one service. This service allows (poten-tially) remotePostItentities to send a copy of themselves to thePostItManager.
The string to give through the invocation is the string storing the state of the entity (position, size, color and text).
//code for receiving a PostIt
LJDescriptionObject fname[] = {new LJString("F"),
new LJString("remoteManager"), new LJString(thisManagerName)};
LJDescriptionObject bname[] = {new LJString("B"), new LJString()};
LJDescriptionObject qname[] = {new LJString("Q")};
LJServiceDescription sdname = new LJServiceDescription(
new LJTree(fname), new LJTree(bname),
new LJTree(qname), 3, 2, 1);
receivePostIt=this.register(sdname);
Noter that thisManagerName (oriol in figure 6.8) is the variable that identifies the manager. Thus if the user wants to change it, the service needs to be removed, and then announced again with the new name in the variable thisManagerName or instead of it.
6.3.3 Development Feedbacks and Foreseen Groupware Application
A first development feedback we have is that testing new versions of the PostIt class was always made at runtime by transferring the state from an
6.4. TOWARD A METHODOLOGY FOR LUCKYJ PROGRAMMING123