Common Repository - Dolphin Pod
davorin....@gmail.com
I would like explore the idea of common repository little further.
We have been missing central repository for free code before, but now
I think it would be even more important.
My idea is not very sophisticated, but it seems to me that it could be
made to work with reasonable effort. However if you have better ideas
what it should do, and how to implement it please raise your voice.
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.
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.
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.
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.
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 assume that all this could be hosted on some dedicated windows
hosting machine, which could be had for reasonably monthly fee.
rush
Andreas Wacknitz
Regards
Andreas
David Gorisek
> 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
Udo Schneider
> I assume that all this could be hosted on some dedicated windows
> hosting machine, which could be had for reasonably monthly fee.
running).
CU,
Udo
Janko Mivšek
I can offer help on the web side of Dolphin public repository - a new
Swazoo v2.0 with streamed file upload and optimized file download is on
the way to Dolphin already, not to mention newest Aida/Web web framework
with Ajax support etc. And I'm also sure that Dolphiners from Aida
community will provide help too.
Best regards
Janko
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
davorin....@gmail.com
wrote:
> 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.
your guidance and advice would make this much better and easier. I
will not be able to come to ESUG, but maybe I could send a collegue of
mine, I have to see.
> 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.
I think GUIDs would still be a good adition to that since, local
repositories may assign same version numbers before they get to be
uploaded to central repository. In that case different GUIDs could
help to differentiate them.
> 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?
Yes, there seems to be a domain and even windows machine available:
Dolphin Harbour!
rush
davorin....@gmail.com
> Yes, there seems to be a domain and even windows machine available:
> Dolphin Harbour!
Oups I may have confused things here, Udo is offering a machine.
One name that I thought of is Dolphin Pad, which means a group of
dolphins.
rush
Udo Schneider
> One name that I thought of is Dolphin Pad, which means a group of
> dolphins.
every other domain in a matter of minutes.
CU,
Udo
David Gorisek
> On Aug 11, 10:34 pm, David Gorisek <da...@remove-this.gorisek.com>
> wrote:
>> 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.
>
> your guidance and advice would make this much better and easier. I
> will not be able to come to ESUG, but maybe I could send a collegue of
> mine, I have to see.
>
Maybe we could also meet in Maribor (if the road takes you in our
direction). After all, if I am not mistaken our locations are only 1
hour drive apart ;-)
davorin....@gmail.com
wrote:
it sounds fine by me, and I think if there is a fit it is good to use
allready existing effort.
rush
davorin....@gmail.com
wrote:
> Maybe we could also meet in Maribor (if the road takes you in our
> direction). After all, if I am not mistaken our locations are only 1
> hour drive apart ;-)
I am a kind of slow driver, so maybe it is a bit more than that, but
we are definitely close :)
As a first shot maybe ESUG is better for kickoff since there might be
more people who could participate. And we could come to visit you if
that does not work out, or even without that cause.
anyway, I need to check few things before I promise something.
rush
Tim M
> 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.
I will be at ESUG - I arrive the evening of the 25th - so we could potentially
coordinate an evening supper to kick start discussions - or meet up the 26th?
Weren't there some others going as well?
I can demonstrate Dolphin running against Subversion - via tortoise as the
ui (which just looks like its part of dolphin) - however the part I was never
able to crack was how to seemlessly load the latest code into the image like
STS does. (Note: while in my image - i am a big fan of STS - although I wish
it had config maps)
Having said this - for distributed development I would like to float the
idea of using something like Mercurial or Bazaar - these are open source
tools that many people use - I don't really want yet another re-invented
version control system. I also want to use something that will version my
graphics and documents along with my ST code - this is very important as
in Dolphin development there are other artifacts.
I have backed off subversion because for many of us to work concurrently,
the models of Mercurial and Bazaar (which are like Monticello by the way)
are for distributed diconnected development - where'as subversion and cvs
are really connected models.
I truly think we could leverage what the rest of the world is using (after-all
Ubuntu has put their muscle behind Bazarr, Apache behind Mercurial).
Anyway - I'm sure a meetup could thrash through the pro's and cons, and would
definitely be interesting.
Tim
pos...@doramail.com
> Having said this - for distributed development I would like to float the
> idea of using something like Mercurial or Bazaar
> I have backed off subversion because for many of us to work concurrently,
> the models of Mercurial and Bazaar (which are like Monticello by the way)
> are for distributed diconnected development - where'as subversion and cvs
> are really connected models.
>
With all due respect, I think the immediate goal should be to figure
out how to set-up a centralized repository using STS, which David is
generously providing for the non-commercial version of Dolphin. The
STS repository would provide a bridge between the non-commercial and
commercial versions of Dolphin.
While there is a need for distributed, disconnected version control
systems, such as Monticello, perhaps that can wait another day---
especially after Monticello2 comes out.
Max
davorin....@gmail.com
> With all due respect, I think the immediate goal should be to figure
> out how to set-up a centralized repository using STS, which David is
> generously providing for the non-commercial version of Dolphin. The
> STS repository would provide a bridge between the non-commercial and
> commercial versions of Dolphin.
I second that opinion, since making a web present STS seems like a job
that can be done in reasonable amount of time and effort, and give us
in return quite good resource that we need rather quickly.
rush
Tim M
>> With all due respect, I think the immediate goal should be to figure
>> out how to set-up a centralized repository using STS, which David is
>> generously providing for the non-commercial version of Dolphin. The
>> STS repository would provide a bridge between the non-commercial and
>> commercial versions of Dolphin.
You guys seem to think its a big job to use already available tools? Not
sure why?
Like I said - I already have subversion working via tortoise and menu items
in the Package and System browsers - I just lack the knowhow to dynamically
load/unload code in the image (although to be honest you don't actually need
to have that feature).
By using a well known repository all of my development tools can use the
same versioning mechanism.
Tim
Udo Schneider
> Like I said - I already have subversion working via tortoise and menu
> items in the Package and System browsers - I just lack the knowhow to
> dynamically load/unload code in the image (although to be honest you
> don't actually need to have that feature).
So if I setup a subversion repositry on the dolphinmap linux server this
might be a quick start for us, correct?
CU,
Udo
davorin....@gmail.com
> You guys seem to think its a big job to use already available tools? Not
> sure why?
>
> Like I said - I already have subversion working via tortoise and menu items
> in the Package and System browsers - I just lack the knowhow to dynamically
> load/unload code in the image (although to be honest you don't actually need
> to have that feature).
>
> By using a well known repository all of my development tools can use the
> same versioning mechanism.
Tim,
before STS came along I have been using Dolphin + CVS, and it kind of
worked, but for me it is not a match for Dolphin + STS. For amount of
work, it seems about the same to integrate svn into Dolphin, as it is
to make STS present on web. So I would definitely vote for web based
STS public repository.
Though, it would be great if you could make your SVN access classes
available, I have at least one use for them allready :)
rush
David Gorisek
with STS. So I have nothing against it.
But let me here just say that in our company we will at least for our
internal needs, implement a web front-end to STS repository plus some
additional functionality which will make it possible to access a remote
STS repository via HTTP directly from Dolphin IDE. This will happen but
not before this winter since we are busy with some other things. Of
course this functionality will we released together with the new version
of STS to community regardless of whether this will be community effort
from the start on or not.
Best regards,
David