Project

General

Profile

1
<?xml version="1.0" encoding="UTF-8"?>
2
<!DOCTYPE article PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN"
3
"http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
4
<article>
5
  <title>Community Mapbuilder State Of Play - June 2005</title>
6

    
7
  <abstract>
8
    <para>I think that we have reached a stage in the Mapbuilder project where
9
    we should look at what we have achieved, look at the state of the software
10
    world around us, and plan our future.</para>
11

    
12
    <para>We have recently seen a number of new names join the Mapbuilder
13
    email list and I invite all our you to contribute to this
14
    discussion.</para>
15
  </abstract>
16

    
17
  <section>
18
    <title>Where have we come from?</title>
19

    
20
    <para>The Community Mapbuilder website started in 2001 as my idea to build
21
    a Geo-Wiki and was originally planned to bring together WMS/WFS-T
22
    components into one easy to configure application. The only thing missing
23
    was a WFS-T client and I started working on the developing Geotools
24
    library to create a Java client.</para>
25

    
26
    <para>In 2003 Raj Singh demonstrated the potential of a web based client
27
    by producing the first prototype web based feature entry client which
28
    talked directly to a database. From then we started mapbuilder-lib,
29
    initially a WMS client, then a WFS-T client which conformed to OGC
30
    standards.</para>
31

    
32
    <para>As we developed further, we joined efforts with Nedjo Rodgers, Mike
33
    Adair, Tom Kralidis and Tom Schuller who were all working on similar
34
    projects. Mapbuider-lib broadened it's scope from being a geo-wiki to
35
    being a robust client to OGC services.</para>
36

    
37
    <para>In mid 2005, Geoserver, an open source WFS-T included mapbuilder-lib
38
    in it's distribution and Mapbuilder started gaining more interest and
39
    attracted more developers.</para>
40
  </section>
41

    
42
  <section>
43
    <title>What are Mapbuilder's Strengths?</title>
44

    
45
    <variablelist>
46
      <varlistentry>
47
        <term>WMS/WFS-T in a browser</term>
48

    
49
        <listitem>
50
          <para>Mapbuilder runs in a standard web browser without requiring
51
          any plug ins. This makes Mapbuilder easy to use for non-technical
52
          users.</para>
53

    
54
          <para>Clients are fast and feature rich because most code is stored
55
          in the client, accessing Web Services using Asynchronous Javascript
56
          And XML (AJAX).</para>
57
        </listitem>
58
      </varlistentry>
59

    
60
      <varlistentry>
61
        <term>Modular design</term>
62

    
63
        <listitem>
64
          <para>Mapbuilder's modular design makes it easy to add extra
65
          functionality.</para>
66

    
67
          <para>Tailored clients are kept small by only including the required
68
          modules.</para>
69

    
70
          <para>We have the opportunity to factor out core modules (like our
71
          projection libraries) to be used and improved by other
72
          projects.</para>
73
        </listitem>
74
      </varlistentry>
75

    
76
      <varlistentry>
77
        <term>Standards compliant</term>
78

    
79
        <listitem>
80
          <para>Standards compliance means that Mapbuilder can build upon the
81
          great work done in the Open GIS services projects.</para>
82
        </listitem>
83
      </varlistentry>
84

    
85
      <varlistentry>
86
        <term>Strong user community</term>
87

    
88
        <listitem>
89
          <para></para>
90
        </listitem>
91
      </varlistentry>
92
    </variablelist>
93
  </section>
94

    
95
  <section>
96
    <title>What software industry developments effect us?</title>
97

    
98
    <para>The advantage of working with Open Source software is that we don't
99
    need to look at competing projects as threats, they are potential
100
    partners. Together we can help each other become better.</para>
101

    
102
    <section>
103
      <title>Asynchronous Javascript And XML (AJAX)</title>
104

    
105
      <para>AJAX describes a way for web browsers to refresh themselves
106
      quickly using asynchronous javascript functions. This functionality has
107
      been available for a couple of years but has only recently become
108
      popular since it's use by high profile Google web sites.</para>
109

    
110
      <para>Recently, a hand full of AJAX library projects have started and
111
      have a strong user base behind them. These project are young and
112
      Mapbuilder still contains a significant amount of AJAX functionality
113
      beyond that provided by the libraries. In particular, Mapbuilder's
114
      Model/View/Controller design pattern and dynamic loading of widgets
115
      would be a useful addition to the AJAX libraries.</para>
116

    
117
      <para>The Mapbuilder project should consider factoring out it's AJAX
118
      libraries and merging them into one of the existing AJAX library
119
      projects.</para>
120
    </section>
121

    
122
    <section>
123
      <title>Other Web Based Geographic Clients</title>
124

    
125
      <para>Mapbuilder currently has a number of features not yet provided by
126
      other Web Mapping Clients, however, there are some features from other
127
      projects that would be nice to include. Where possible, we should try to
128
      collaborate with these projects and merge our efforts. We can do this by
129
      factoring out and sharing common libraries or merging our efforts into
130
      one project.</para>
131
    </section>
132

    
133
    <section>
134
      <title>Geoserver</title>
135

    
136
      <para>Geoserver, the Open Source WMS/WFS has incorporated Mapbuilder
137
      into it's release. This is a good relationship for us because:</para>
138

    
139
      <itemizedlist>
140
        <listitem>
141
          <para>We are getting exposure with our core potential user
142
          base.</para>
143
        </listitem>
144

    
145
        <listitem>
146
          <para>We are seeing developers join Mapbuilder from the Geoserver
147
          project.</para>
148
        </listitem>
149
      </itemizedlist>
150

    
151
      <para>Gabriel Roland pointed out that we can make cross development
152
      easier by using similar tools. In particular, we should consider moving
153
      some functionality from Sourceforge to <ulink
154
      url="http://www.codehaus.org/">http://www.codehaus.org/</ulink>.</para>
155
    </section>
156

    
157
    <section>
158
      <title>Geographic Wiki</title>
159

    
160
      <para>Significant interest is developing for a Geographic Wiki, where
161
      many people can collaboratively build geographic maps. Mapbuilder would
162
      be an ideal client for a Geographic Wiki and we should aim be involved
163
      in any such project.</para>
164

    
165
      <para>This will introduce a many new challenges, like handling user
166
      authentication.</para>
167
    </section>
168

    
169
    <section>
170
      <title>Content Management Systems (CMS)</title>
171

    
172
      <para>Content Management Systems are one of the big potential users of
173
      Map Viewers and Feature Entry Clients. Unfortunately there are hundreds
174
      of CMS products and there doesn't seem to be a standard
175
      interface.</para>
176

    
177
      <para>Java CMS seem to be a better position with standard portlet
178
      specifications and we may be able to target these first.</para>
179

    
180
      <para>Nedjo Rodgers notes that Mapbuilder contains many components
181
      needed by CMSs and that different CMSs will all face similar problems.
182
      We should encourage the development of a CMS integration toolkit.</para>
183
    </section>
184

    
185
    <section>
186
      <title>Browser support for SVG</title>
187

    
188
      <para>It seems that version 7 browsers will provide SVG support by
189
      default. This means that we can make use of SVG's more powerful
190
      rendering and we can expect average users will still be able to use our
191
      web pages.</para>
192
    </section>
193

    
194
    <section>
195
      <title>Use stable release numbers</title>
196

    
197
      <para>Mike Adair notes that potential users are scared by our "alpha"
198
      version numbers. We should create a 1.0 release and advertise the
199
      existence of applications using Mapbuilder.</para>
200
    </section>
201
  </section>
202

    
203
  <section>
204
    <title>Opportunities for improvement</title>
205

    
206
    <section>
207
      <title>Testing</title>
208

    
209
      <para>With only two core developers, and while software was still in
210
      alpha state we were able to get away without automated testing. However
211
      we are now at a stage where we should consider automated testing
212
      frameworks like jsunit.</para>
213

    
214
      <para>Advantages of automated testing includes:</para>
215

    
216
      <itemizedlist>
217
        <listitem>
218
          <para>We can easily test Mapbuilder against new browsers and
219
          platforms as they become available.</para>
220
        </listitem>
221

    
222
        <listitem>
223
          <para>We can test our updates don't break another part of the code.
224
          This is more important as the software becomes more complex and
225
          there are more developers working on sections we are not familiar
226
          with.</para>
227
        </listitem>
228

    
229
        <listitem>
230
          <para>Software can be released more frequently because the head
231
          version of the software should always be working.</para>
232
        </listitem>
233

    
234
        <listitem>
235
          <para>Our releases should become more robust.</para>
236
        </listitem>
237
      </itemizedlist>
238
    </section>
239

    
240
    <section>
241
      <title>Design Patterns</title>
242

    
243
      <para>There are a number of areas in Mapbuilder which could be improved
244
      by the introduction of design patterns. Good use of design patterns will
245
      simplify the code and make it easier to maintain. We should review then
246
      refactor our code for this.</para>
247
    </section>
248

    
249
    <section>
250
      <title>Memory Leaks</title>
251

    
252
      <para>Memory leaks in a browser can cause a browser to crash or
253
      significantly slow a computer down. We were not considering Memory Leaks
254
      when writing the code, so they probably exist. We should be able to
255
      minimise Memory Leaks if we use an AJAX library which addresses
256
      leaks.</para>
257
    </section>
258

    
259
    <section>
260
      <title>Documentation</title>
261

    
262
      <para>While we have made a start our documentation needs to be updated.
263
      Good documentation is essential for attracting and keeping potential
264
      developers.</para>
265

    
266
      <para>Nedjo Rodgers and others noted that we need concrete guides for
267
      developers. For example, A guide for creating widgets. This should be
268
      combined with mentoring from core developers.</para>
269

    
270
      <para>Chris Holmes noted that it is easier to build documentation in a
271
      wiki as it is continuously updated by users. In particular we should
272
      consider using Codehaus.</para>
273
    </section>
274

    
275
    <section>
276
      <title>Professional Look and Feel</title>
277

    
278
      <para>Feedback I've been getting often includes "The technology is
279
      great, but we need a sexy interface to sell Mapbuilder to decision
280
      makers". We need to provide a sexy interface to Mapbuilder and we need
281
      to ensure we have a stable demonstration release.</para>
282
    </section>
283
  </section>
284

    
285
  <section>
286
    <title>Recommendations</title>
287

    
288
    <variablelist>
289
      <varlistentry>
290
        <term>AJAX</term>
291

    
292
        <listitem>
293
          <para>Contact AJAX library projects, suggest working toward a common
294
          AJAX library then coordinate exporting Mapbuilder functionality into
295
          one of these projects.</para>
296
        </listitem>
297
      </varlistentry>
298

    
299
      <varlistentry>
300
        <term>Projection Libraries</term>
301

    
302
        <listitem>
303
          <para>Export the projection libraries into a separate project so it
304
          can be used by other projects.</para>
305
        </listitem>
306
      </varlistentry>
307

    
308
      <varlistentry>
309
        <term>Review design</term>
310

    
311
        <listitem>
312
          <para>Review the design, introduce design patterns, refactor
313
          code.</para>
314
        </listitem>
315
      </varlistentry>
316

    
317
      <varlistentry>
318
        <term>Update documentation</term>
319

    
320
        <listitem>
321
          <para>In particular, concrete examples of how developers should do
322
          specific tasks (like creating a widget).</para>
323
        </listitem>
324
      </varlistentry>
325

    
326
      <varlistentry>
327
        <term>Produce a Professional Look and Feel</term>
328

    
329
        <listitem>
330
          <para></para>
331
        </listitem>
332
      </varlistentry>
333

    
334
      <varlistentry>
335
        <term>Codehaus</term>
336

    
337
        <listitem>
338
          <para>We should ask if we can get Mapbuilder hosted on
339
          http://www.codehaus.org. It provides subversion, better bug
340
          tracking, a wiki for documentation, and is used by Geoserver and
341
          Geotools, projects which we aim to align ourselves with.</para>
342
        </listitem>
343
      </varlistentry>
344

    
345
      <varlistentry>
346
        <term>SVG</term>
347

    
348
        <listitem>
349
          <para>We should encourage developers who may be interested in adding
350
          SVG support.</para>
351
        </listitem>
352
      </varlistentry>
353

    
354
      <varlistentry>
355
        <term>CMS</term>
356

    
357
        <listitem>
358
          <para>We should encourage the development of a CMS integration HOWTO
359
          and collaboration from people integrating Mapbuilder into different
360
          CMSs.</para>
361
        </listitem>
362
      </varlistentry>
363

    
364
      <varlistentry>
365
        <term>Create a 1.0 release</term>
366

    
367
        <listitem>
368
          <para>We should create a 1.0 release and advertise the existence of
369
          applications using Mapbuilder.</para>
370
        </listitem>
371
      </varlistentry>
372
    </variablelist>
373
  </section>
374
</article>
(2-2/3)