TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Kihup Boo <[log in to unmask]>
Reply To:
Kihup Boo <[log in to unmask]>
Date:
Fri, 5 Jan 2001 10:29:39 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (75 lines)
Regarding collaborative development environments, I like the way
the XML projects are being done at Apache using CVS.
http://xml.apache.org

On top of it, to enable an Ada compiler as a Web service, we have done
something similar using CGI. Basic idea is for any participating user being
able to
initiate a build by clicking a button on a HTML page. This will invoke a
make file on the web server that compiles the source code based on target
platform information given, and the results can be downloaded through
another well-known html page.

One minor problem is for an administrator to monitor the disk usage to
prevent
the storage from being used up.


----- Original Message -----
From: Doug Smith <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, January 03, 2001 9:20 PM
Subject: Let's revisit WebAda...Web-enabling an Ada Compiler


> All,
>
> So let's imagine I can resurrect WebAda.
>
> First, it did not generate executables. But with JGNAT, I'm optimistic
that we can build a Java byte code executable to deliver to the user to run
safely on their own machine. Other ideas are welcome.
>
> However, one of the least appealing facets of WebAda was the use of the
user's IP Address to create and maintain a separate work area where WebAda
stored source and object files. Although it did not require
Username/Password, it obviously created problems for users who wanted to
work from different sites or used an ISP with dynamic IP addressing.
>
> Coincidentally (or not), I've been working in the area of Web-enabled
applications for several years and understand much more of what is possible.
We can use e-mail addresses for username and authenticate with passwords,
etc. Again, suggestions are welcome - but I can work out the obvious - tell
me of the not so obvious.
>
> The initial WebAda used the model that all source was publicly visible.
When someone discovered or was given a link to some source code, they could
view and optionally compile into their own work area, implicitly making a
copy of the source. I wanted to encourage collaboration, but this seemed too
simplistic.
>
> The real problem is how to architect these individual work areas in such a
way that communities of collaborating developers grow dynamically and
successfully. What should the rules be for sharing code, copying code, etc.?
How would GNAT's 'library-less' model fit well in a web-enabled Gnat
compiler (without changing Gnat). This will also be resurrected on a Unix
box (most likely), so consider the permission issues if you like, although
I'm not sure which Web Server product will be used.
>
> Should a user be able to specify whether their source is visible to other
WebAda users? Public? By a group name? Should a body be visible? Will
versioning and CM be required to avoid chaotic problems? Or will users
negotiate through these problems on their own?
>
> If you are interested in brainstorming or have leads on technical sources
that discuss collaborative development environments and their architectures,
let me know. I don't want to re-invent the wheel! If there are enough people
interested, we can start a mailing list.
>
> I look forward to the simple, elegant ideas that seem to make Web
solutions so fascinating - and easier to implement 8^)
>
> [log in to unmask]
> 703-742-8662
>

ATOM RSS1 RSS2