Re: Common Repository - Dolphin Pod
- From: David Gorisek <david@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 11 Aug 2007 22:34:48 +0200
davorin.rusevljan@xxxxxxxxx wrote:
The idea is to use STS as a core of the system, put the dolphin image
running the STS on the web server, and handle upload of new stz
version as STS import. Similary, server would make available for
download all versions of package as export stz.
That's exactly the way I always meant to do it. We have all the needed web and AJAX frameworks available since this would work on the same basis as WikiDoc and all the rest of web applications that we make in our company. I could make such a system in about a week but at this time I don't have that much time to dedicate to this goal. Maybe if there will be someone at the coming ESUG conference we could then set out the foundations for the web application and then jointly develop the needed functionality.
By extending a client part of STS, from Package Editions Browser, we
should be able to import versions of package from public repository,
and in similar way send a package version into the public repository.
Yes, this would be an AJAX-ified web client acting like the package editions browser plus another view for the project editions browser.
To enable easier and more efficient client side logic, web server
would also support some additional methods like list of all packages,
list of versions for particular package, etc.
Uploads and downloads would be a bit larger than in CVS for instance,
since full versions and not just diffs would be transfered, but it
seems to me that average stz size is still acceptable.
STZ and STP files are zipped XML files so that files aren't really big.
Some things would need to be addressed, one of them is that STS is not
very good at keeping track of which version is derived from which when
one uses exports and imports. (imports basically starts a branch from
the beginning), It seems to me that this could be solved by assigning
GUIDs to each version, so it would be easier to track versions in
distributed environment.
I am aware of this. Currently a package or project edition only keeps track of a single previous version. For this to work it should keep track of all previous versions i.e. the chain of previous versions.
Lastly, maybe not mandatory, is the small file archive. Some packages
need some supporting files, like icons, bitmaps, dll's. So simple file
archive object could be attached to the package (or project). Archive
would contain list of file paths in image or package relative way,
file attributes and file contents.
I know of some users that already implemented such functionality but not in the optimal way...
I assume that all this could be hosted on some dedicated windows
hosting machine, which could be had for reasonably monthly fee.
Well, from my point of view that's the least of the problem. This would not be a high traffic application so I see no problem if we host this on our server farm for free (except this would be on a Linux/Wine server not on Windows). And should the traffic ever really grow, then we wont complain either because after all this is our goal - the growth of the Smalltalk community. Has anyone got the domain name already?
Best regards,
David
.
- Follow-Ups:
- Re: Common Repository - Dolphin Pod
- From: Tim M
- Re: Common Repository - Dolphin Pod
- From: davorin . rusevljan
- Re: Common Repository - Dolphin Pod
- References:
- Common Repository - Dolphin Pod
- From: davorin . rusevljan
- Common Repository - Dolphin Pod
- Prev by Date: Re: Future of Dolphin
- Next by Date: Re: Future of Dolphin
- Previous by thread: Re: Common Repository - Dolphin Pod
- Next by thread: Re: Common Repository - Dolphin Pod
- Index(es):
Relevant Pages
|
