Re: Bibliocello proof of concept

[Dale Henrichs]

I've created a mailing list for bibliocello:

http://groups.google.com/group/bibliocello

If you're interested in tracking/contributing (ideas and/or code) sign up.

I've taken the proof of concept a little bit farther:

- solved the 'pier nesting problem'
- added a security model for RESTful API
- added structured repositories (see attached png). Each project can
have multiple repostories with permissions defined on a per
repository basis

If you load the code and launcher bibliocello, you can read about things
in a little more detail under the News tab.

I think that bibliocello should be used to build bibliocello and with
the current level of functionality (GET/PUT of mcz files) the
implementation can be used.

I should be putting up a bibliocello site hosted by GemStone this week
sometime. Right now it will function as a Monticello repository that can
be accessed from Squeak/Pharo/GemStone and that's about it. I expect the
site to be refreshed from scratch regularly, so nothing that is not
backed up elsewhere should be stashed there:). With this in mind, I will
arrange for the mcz files stored in bibilocello to be stored in
Gemsource as well...I think that the pier content that gets generated
should be trasnferred to the code (in the Bibliocello-Setup package) for
safe keeping ...

There are several different directions that can be pursued right now and
the things that get worked on will be driven by the folks who have
opinions and those who are willing to contribute code...

Right now my thinking is that the RESTful API is the primary focus, this
allows for multiple client GUIs. The additional RESTful functions that
might be interesting to pursue here:

- create new projects
- create new create new repositories in a project
- delete mcz files/repositories/projects

I know that some of you are very interested in code analysis (Famix?) so
this is another area that's wide open. I will tinker in this area with a
couple of proof of concept style projects just to keep the ball rolling,
but if someone has energy in this area I'll gladly step away ... If
something needs to be ported to GemStone, I will step up to that and
then get out of your way:)

The design/structure for the Pier-base interface is still a bit in flux
... I'm not a GUI designer so manipulating CSS and designing page
layouts are not my forte, but I do feel (fairly) strongly that a
web-based UI for doing basic manipulation in parallel with the API is
needed, so if no one steps up for web design, you'll get something
(ugly) from me:)

Someone with good Pier foo (or willing to acquire Pier foo) would be a
welcome:)

Dale

[Dale Henrichs]

Philippe Marschall wrote:
> 2010/7/27 Dale Henrichs <dhen...@vmware.com>:

>> I've created a mailing list for bibliocello:
>>
>> http://groups.google.com/group/bibliocello
>>

> Let me know if you need some features in Seaside-REST, like
> un/marshalling or POST variable binding.
>
> Cheers
> Philippe

Philippe,

I've found that I'm constructing complex routes that look like this:

<Path: '/projects/{projectName}/{fileName}.mcz'>
<Path: '/projects/{projectName}/{r1}/{fileName}.mcz'>
<Path: '/projects/{projectName}/{r1}/{r2}/{fileName}.mcz'>

where the /{r1}/{22}/ is a structural path for repositories (in this
case). It isn't too bad right now, but I expect to be performing
multiple commands on the mcz files, which will lead to an explosion of
methods:

<Path: '/projects/{projectName}/{fileName}.mcz'/classes>
<Path: '/projects/{projectName}/{r1}/{fileName}.mcz'/classes>
<Path: '/projects/{projectName}/{r1}/{r2}/{fileName}.mcz'/classes>

<Path: '/projects/{projectName}/{fileName}.mcz/methods'>
<Path: '/projects/{projectName}/{r1}/{fileName}.mcz/methods'>
<Path: '/projects/{projectName}/{r1}/{r2}/{fileName}.mcz/methods'>

I would much rather construct the path doing something like the following:

<Path: '/projects/{projectName}/*pathTerms*/{fileName}.mcz'>
<Path: '/projects/{projectName}/*pathTerms*/{fileName}.mcz'/classes>
<Path: '/projects/{projectName}/*pathTerms*/{fileName}.mcz/methods'>

where the *pathTerms* allowed for multiple (or zero) path components.

Also, something like the following would also be even cooler:

<Path:
'/projects/{projectName}/*pathTerms*/{fileName}.mcz/[classes|methods]'>

where the [class|methods} resolved to a path matching classes or methods...

Do you have some ideas along these lines?

Dale